Gevaarlijke bug in Drupal 7 maakt cms gevoelig voor sql-injecties - update

Het opensource-cms Drupal kampt in versie 7 met een bug in de zogeheten database abstraction api. Hierdoor kunnen kwaadwillenden sql-injecties uitvoeren op kwetsbare websites. Drupal noemt de bug zeer kritiek en heeft update 7.32 uitgebracht.

De bug in Drupal Core, de basis van het cms, is pijnlijk te noemen voor Drupal: de database abstraction api is juist bedoeld om databasequeries te controleren op de geleverde input. Bovendien werd de fout in de code al bijna een jaar geleden publiek gepost op de website van Drupal. Het blijkt desondanks mogelijk om sql-injecties uit te voeren op Drupal-websites die draaien op versie 7.x. Hierdoor kan een aanvaller adminrechten verkrijgen en onder andere gegevens buitmaken, verwijderen of een website offline halen.

Drupal noemt de bug 'zeer kritiek' en heeft inmiddels versie 7.32 uitgebracht om het gat te dichten. Gebruikers van Drupal 7.31 en lager wordt aangeraden om zo snel mogelijk de update te installeren. Drupal-gebruikers die hun website niet zelf kunnen updaten kunnen met een aanpassing van de code in het bestand 'database.inc' ook handmatig een reparatie uitvoeren. Versie 6.x is overigens niet kwetsbaar voor deze aanvalsmethode.

Update, 20.00: De bug zit ook in de beta van Drupal 8. Er is een update uitgebracht om de bug te verhelpen.

Reacties (102)

Kan PHP niet afdwingen dat de programmeurs op zo'n manier moeten programmeren dat er geen SQL injecties meer mogelijk zijn? In .NET lijkt het me beter geregeld.

Nee, je hebt verschillende adapters die je kunt gebruiken (PDO / mysql (deprecated) / mysqli), maar in elke kun je een keiharde query rammen die ie 1 op 1 uitvoert.

Zolang je PDO gebruikt en prepared statements uitvoert zit je 100% veilig, en verder hebben zo goed als alle frameworks tegenwoordig wel een ORM-abstractielaag bovenop de database, om bijv. domain models direct te kunnen saven en loaden, die je de zorgen van queries uitvoeren al uit handen nemen.

Het is dus echt niet nodig om dergelijke shit in je code te hebben, tenzij je - net als Drupal 7 - nog volop legacy rommel gebruikt overal. Drupal 8 bevat componenten van Symfony 2, en zal dus hopelijk beter geregeld zijn (hoewel je altijd aan kan blijven rommelen).

/edit

Voor de geïnteresseerden: de patch pakt niet meer in een loopje de key én value op, maar doordat je 'm door array_values heen trekt wordt de key weggeflikkerd (die zorgt voor het probleem blijkbaar) en wordt dit vervangen voor een index, dus 0, 1, 2, enz.

[Reactie gewijzigd door _eXistenZ_ op 16 oktober 2014 14:01]

die lagecy rommel (zo als jij het niet) komt ook omdat drupa l7 eerste release uit 2011 komt en development begon in 2008. met als doel om op php 5.3.x te werken.

Ook kan drupal overweg met database systemen die (nog) niet mogelijk zijn met PDO (NOSQL bijvoorbeeld)

De symfone 2 weg die met Drupal 8 is ingeslagen zal idd veel dingen beter maken en meer OO (en dus ook beter overweg kunnen met dit soort 'loopholes'. maar die 'shit' hoort dus tot dan echt wel in de code. al was het maar om beginnende devvers te beschermen tegen hun eigen onkunde. (en niet veel vaker en meer SQL-injecties tegen te komen)

Php ondersteund inderdaad een oudere variant van PDO. maar dat is nieuwer dan dat D7 begon met ontwikkelen. (5.3.0 komt van Version 5.3.0 30 Jun 2009 bron:http://php.net/ChangeLog-5.php#5.3.0)
Verder is PDO ook geen miracle cure, had het nog wel eens problemen in het begin en waren er maar een paar devvers die het genoeg beheerste om die code uberhoud te schrijven (toen der tijd). en ten slote, drupal is open source.. dus waarom heb jij het niet gefixed toen, of is dat ook te kort door de bocht
Edit: toegevoegd reactie op _eXistenZ_ @16:15

[Reactie gewijzigd door Sysosmaster op 16 oktober 2014 16:56]

PHP 5.3 ondersteunt ook gewoon PDO, en bijv. daarop een ORM-laag, maar Drupal 7 loopt zelf gewoon achter als het aankomt op design patterns / technieken en is niets meer dan een doorontwikkeling van Drupal 6. Drupal 8 wordt wel echt anders.

Dus in .NET kun je geen SQL injecties meer toepassen?
Wat als ik je zeg: dat kan je wel.

In PHP heb je net zoals in .NET mogelijkheden om het te vermijden.
In .NET heb je bijvoorbeeld een LINQ-TO-SQL, in PHP heb je bijvoorbeeld een DBAL.

Maar uiteindelijk is het nog steeds aan de ontwikkelaar.
En dat terwijl het tegenwoordig echt geen moeite meer is, gewoon de variable input in je query vervangen door een "?", en daarna kan je de variables erin steken (met typing).

Toen ik nog naar school ging, was het zelfs de regel: als er SQL injectie mogelijk is (maakt niet uit hoe miniem, je moest er maar mee rekening houden) had je meteen een 0 voor het ganse werk, ongeacht hoe goed het voor de rest gecodeerd was. Dit is dan ook iets dat niet meer zou mogen voorkomen, simpel tegen te gaan.

Linq-To-Sql is al oud en vervangen door Entity Framework. Maar sowieso zijn alle SQL queries die vanuit Linq door .NET Framework worden omgezet naar SQL queries toch beschermd tegen SQL injecties?

Sinds wanneer is het verplicht om Entity Framework of Linq to SQL te gebruiken?

Ado.Net is nog steeds prima mogelijk. (En ook wel eens handiger dan EF).

Gebruik je in Ado.Net geen parameters dan kun je gewoon vatbaar zijn voor SQL injection.

En om deftig overweg te kunnen met EF heb je Linq nodig.
In essentie is het nog steeds Linq.
Even dat rechtzetten dus.

Ik ben niet bekend met .NET noch Entity framework, maar het klinkt qua naam als zijnde een ORM-systeem. Nu is dat heel handig om persistentie van je objecten in je code te bewerkstellingen en voorkomt het wat dat betreft ook alle SQL-injection aanvallen (mits het framework goed in elkaar zit natuurlijk).

Qua performance zijn die dingen vaak om te huilen en als je zware / complexe queries moet doen of heel veel repetitieve queries met verschillende waarden is het doorgaans vele malen efficienter om de queries zelfs op te stellen. Vanaf dat moment heb je als developer de volledige verantwoordelijkheid om je code tegen SQL injecties te beschermen.

Afhankelijk van je doeleinden zul je dus soms genoodzaakt zijn om voorbij het ORM te stappen, omdat je anders minuten of uren zit te wachten op iets wat ook in seconden had gekund.

Ook in .NET kun je vatbaar zijn voor SQL Injection.

PDO beschermt al minstens tegen 1st order injection, maar wordt nog steeds niet genoeg gebruikt.
Probleem is dat vele commerciële Drupal 7 omgevingen nog onder 5.3 of ouder draaien, en dus zal iets forceren in een nieuwe PHP versie niet veel uitmaken.

Wellicht omdat Drupal 7 officieel ook uitgaat van 5.3 (want alweer een paar jaar oud). Draait hier lokaal prima op 5.4 hoor, maar de notices vliegen je om de oren

Wellicht omdat Drupal 7 officieel ook uitgaat van 5.3 (want alweer een paar jaar oud). Draait hier lokaal prima op 5.4 hoor, maar de notices vliegen je om de oren

Dan doe je toch iets gruwelijk fout, hier 0,0 notices op 5.5.

A jij bent degene die met alleen drupal core uit de voeten kunt?

Voordat we in een flamewar verzanden .... wil niks meer zeggen dan dat Drupal op moment van release van een major versie een keuze maakt mbt php en mysql versie en zich daar aan houdt, Drupal 6 en php 5.3 was ook niet liefde of het eerste gezicht zal ik maar zeggen En ja ik weet er is verschil tussen een notice en een fatal error...

Zeer kriktiek en dan heeft het toch een jaar geduurd om te fixen...

Dat lijkt me niet al te best.

Kortom, de regel code in /includes/database/database.inc vervangen van:

• foreach ($data as $i => $value) {

naar

• foreach (array_values($data) as $i => $value) {

'Probrem sloved'...

[Reactie gewijzigd door cappie op 16 oktober 2014 18:47]

Zo te lezen heeft niemand het serieus genomen.

Niemand behalve de reporter heeft het issue gezien, omdat het in een inactieve queue stond. Er zullen waarschijnlijk maatregelen komen om zoiets in de toekomst te voorkomen.

Security fixes zitten blijkbaar normaal in een private queue zodat niemand er misbruik van kan maken en het gefixt kan worden. Daar is het dus mis gegaan, gewoonweg verloren tussen alle kleine klote bugs..

Dit komt voornamelijk doordat deze niet op de correcte manier is gerapporteerd aan Drupal.

Beetje arrogant die ontwikkelaars van Drupal niet ? Als ik zeg dat je voorwiel plat is, antwoord jij dan gelieve dat per briefwisseling te laten weten ?

Als je een groot project hebt zoals Drupal, dan is het van belang om dit soort communicatie in goede banen te leiden. Er is zoveel communicatie rondom het project, dat het de developers dat niet allemaal bij kunnen en willen houden. Dan kan het zomaar gebeuren dat een gerapporteerde bug niet wordt opgemerkt juist omdat deze niet via de daarvoor bestemde kalenen is aangeleverd.

Ok, maar je kan niet altijd verwachten dat derden in 100.0000% van de gevallen juist kunnen beoordelen in welk hokje jij het wil stoppen. Een security meldpunt is zeker een goed idee, maar ontneemt je dus niet van de taak om je algemene issue tracker in de gaten te houden.

Uiteraard. Maar ik reageerde alleen op svennd die suggereerde dat elke manier van rapporteren opgemerkt had moeten worden. Inclusief bijvoorbeeld een opmerking van iemand in het forum op de site of zoiets. Althans, zo kwam het op mij over, en dat is gewoon niet haalbaar.

[Reactie gewijzigd door ATS op 16 oktober 2014 14:11]

Meh, ik lees het als 'Als ik [middels de issue tracker] zeg dat je voorwiel plat is.'

De manier van melden was nog steeds een eigen kanaal en geen willekeurig k*tforum (!). Je kan hoogstens hinten dat er in het vervolg een beter kanaal bestaat, maar je zou het je klokkenluiders niet kwalijk moeten nemen; het hebben van het lek, en het niet zien na 1 jaar blijft keihard je eigen probleem.

Hebben ze bij Drupal geen community-managers dan?
Het zou mijn inziens binnen het takenpakket van een dergelijk iemand liggen om bugs die via een verkeerd kanaal binnenkomen, naar het juiste kanaal te dirigeren.

Ik vind het voorbeeld wat je geeft niet zo goed, want als je het mondeling verteld is het ook goed, je weet dat je het aan de juiste persoon hebt verteld. Maar als ik een lekke band zie, en ik vertel dat hardop zonder dat de eigenaar van de fiets dat hoort (omdat ie ergens anders is) dan heeft dat geen zin. Anderen horen het misschien wel, maar als die de eigenaar niet kennen... Zoiets is hier namelijk gebeurd.
Het niet als bug aangemeld maar gepost op de website. Geen garantie dat dat aankomt bij ontwikkelaars. Je kunt namelijk niet verwachten dat de ontwikkelaars alle posts lezen en daar bugmeldingen vandaan halen, als er een speciale website is om bugs te melden: https://www.drupal.org/us...on=node/add/project_issue

Klopt, maar met een community als drupal verwacht je toch wel dat zelfs al is het verkeert gepost dat het doorgegeven wordt, in het juiste hokje... maar ik neem m'n woorden terug, de ontwikkelaar is hier natuurlijk niet 100% in de fout, maar de community of mensen rondom het project die beslist het gevaar niet zagen of niet wouden zien.

Het antwoord dat je ziet is van gisteren, dus na de fix. Daarvoor is het issue nooit opgemerkt.

Niet correct? Hij stond gewoon netjes op de issue tracker van Drupal. Blijkbaar heeft Drupal een aparte issue tracker voor security issues, wat die persoon mogelijk niet wist. Daarnaast: als je de bug report leest dan zie je dat de vinder niet zeker wist of SQL injection wel mogelijk was. Ik wijt dit dus eerder aan slordigheid van Drupal; de bug is netjes gerapporteerd en er is gewoon niets mee gedaan.

Een bericht over de security tracker staat boven het issuemeldformulier. Het issue is als een feature request gemeld.

Mogelijk komt er een team om de bredere queue in de gaten te houden.

Nou, ik vind het ook slecht dat feature requests nauwelijks bekeken worden. Bekijken ze die jaarlijks? Of niet bekeken door de juiste personen. Iemand met verstand had wel door gehad wat voor vreemde feature request dit is.

Feature requests worden nooit in een al uitgegeven major branch (7.x) toegevoegd. Daarom heeft dit een zeer lage prio.

Die policy zal met het nieuwe releaseschema van Drupal 8 veranderen. Het secteam kijkt of men iets kan doen aan zulke weesissues in de normale issue queue.

Maar degenen die de bugtracker in de gaten moeten houden hebben dit blijkbaar ook niet goed afgehandeld, dwz die zouden de issue zelf naar de security tracker moeten verplaatsen (en waarom die anders zijn snap ik ook niet helemaal - mogelijk heeft het te maken met zichtbaarheid, maar ook dat zou eenvoudig af te vangen moeten zijn).

Nog erger is dat er al 7 maanden geleden een patch voor was. De fix is belachelijk simpel en het probleem zelf is gewoon slordig programmeerwerk.

Iemand een idee hoe alle updates handmatig kunnen uitgevoerd worden ?

Ik ga naar/maak een lege directory op mijn server en download daar met wget de nieuwe Drupal core van https://www.drupal.org/project/drupal, dus:
wget http://ftp.drupal.org/files/projects/drupal-7.32.tar.gz
Dan uitpakken:
tar -zxvf drupal-7.32.tar.gz
Dan eerst de Drupal root leeghalen BEHALVE "/sites" want daar staan je eigen aanpassingen en de settings.php meestal.
vervolgens kopieer je de uitgepakte bestanden naar de net leeg gemaakte map (behalve /sites).

Edit: Eerst even je site in maintenance mode zetten en daarna upgrade.php draaien (http://site.com/upgrade.php)

[Reactie gewijzigd door teek2 op 16 oktober 2014 14:40]

Dikke merci we zijn namelijk nog een paar versies achter en er treden steeds fouten op met witte pagina's. Het niet in maintenance mode zetten is daar al één oorzaak van geweest in de beginne.

Ik liep zelf ook al flink wat versies achter, ik dacht eigenlijk dat ik wel een melding zou krijgen zoals bij modules die geupgrade moeten worden maar dat was blijkbaar niet zo...

Ik krijg elke keer netjes een melding van drupal.
Wellicht staat er ergens iets niet goed?

Als je klaar bent met patchen: lees je 'even' in in git en drush. Kost enige in spanning, maar je volgende patch kan zo simpel zijn als drie of vier commando's.

drush archive-dump ; git pull ; drush cache-clear all

[code]drush up drupal[/code] als je commandline tot je beschikking hebt update alleen core files (en eventueel database als nodig) en maakt automatisch een backup. 'drush up' update alles. drush up 'modulenaam' doet alleen de genoemde module/theme.

Dit is een paar seconden werk zo. Drush is een huge timesaver.

ftp + notepad

Had ik al door Cergorach , maar de code van de updates waar vind je die ?

@TT17, de patch is te downloaden op https://www.drupal.org/fi...SA-CORE-2014-005-D7.patch
(zoals beschreven in de Notes en de SA) https://www.drupal.org/SA-CORE-2014-005

je kunt ook teek2 zijn oplossing pakken.

maar als je enkel wilt patchen (en idd de instructies staan ook in UPGRADE.txt maar betere staat op https://www.drupal.org/patch/apply) als je toegang hebt tot patch gebruik dat, anders. zoek in de patch file naar de naam en locatie van de fix (staat er gecodeert maar leesbaar in) en vervang de regels die gespecificeerd staan met de regels van de patch. als dit niet lukt kun je altijd nog hulp vinden op IRC in freenode/#drupal

Even de UPGRADE.txt doorlezen in de root van Drupal. Valt wel mee qua werk.

Thanks !

Ik vraag me toch af hoe dit steeds weer kan gebeuren. Je zou toch verwachten dat iedereen nu wel weet dat dit een groot gevaar is en dat je beter in alle gevallen gewoon prepared statements kunt gebruiken (die ook onder alle bekende databases gewoon ondersteunt worden).

Er is wat mij betreft geen enkel excuus voor dit soort exploits, hier hebben de developers gewoon zitten slapen.

Dit zijn prepared statements, het probleem is alleen dat ze dynamisch gegenereerde prepared statements zijn waar injectie weer in mogelijk wordt.

nu is het alsnog aan de website beheerders om hun cms te updaten... dat zal lang niet in alle gevallen snel gaan

Ik heb nooit begrepen waarom "de programmeur" geen gebruik maakt van native sql parameters ipv het sql statement manueel samen te stellen? Hierdoor voorkom je toch sql injecties?

De fout zit in een stuk code die dergelijke placeholders toevoegd. Deze zgn placeholder expansion is in drupal core gekomen omdat een variabel aantal placeholders bij oa IN() clauses vaak problemen opleverden voor module auteurs. Die kozen dan vervolgens oplossingen die SQL-i mogelijk maakten.

Als je bij bent met updates is dit echt een hele simpele update.

Wij hebben gisteren met 2 man bijna 250 Drupal sites van de update voorzien, waarvan 90% in een half uur, en de rest in het uur daarna.

Drupal, Drush en Git ... zo relaxed!

voeg aliases toe en je kunt het (bijna) automatisch doen

voeg aliases toe en je kunt het (bijna) automatisch doen

Ehm, ik heb eigenlijk geen idee wat dat zou toevoegen ... wij gebruiken drush make voor het genereren van een installatieprofiel, daarna gaan alle wijzigingen via DTAP (binnenkort git flow) door naar productie.

Niet-multi sites idem: maar daar zijn vaak geen installatieprofielen voor.

Of je gaat gelijk over op Aegir, kun je ondertussen een film kijken ofzo

aegit is alleen handig als de site's similar zijn... maar aliases is flexibeler

Eens, al heb ik ook wel eens iets gelezen van iemand die zijn hele toko op aegir draaide. Lijkt mij ook niet heel handig, maar er is geen limiet op het aantal platforms ofzo

Of je gaat gelijk over op Aegir, kun je ondertussen een film kijken ofzo

Hebben we getest, conclusie is dat we het verschrikkelijk vonden. Aegir sloopt (net als bv Plesk en al die andere rotzooi) de kracht van keuzes, en (wat Sysosmaster ook zegt) gooit al je sites op 1 hoop; moet je niet willen.

Er is geen enkele goed argument te verzinnen dat een mysql injectie anno 2014 kan verantwoorden.

Gepost in verkeerde thread

[Reactie gewijzigd door RRX op 30 oktober 2014 12:18]

Dat hoor ik over wel meer CMS Systemen. Dus wat zou een goed ondersteunt alternatief zijn?

maatwerk?

heb vaak genoeg wordpress/magento/joomla sites omgebouwd naar een eigen cms, als je je klant daarvan kan overtuigen (en ook de seo partij aan boord kan krijgen, aangezien die nog wel eens blind wordpress willen, want: wordpress)

als je dat goed opzet, is het cms superclean (want: er zit NIKS in wat je niet gebruikt en ALLES zit op een logische plek) en je hebt geen frankenstein code omdat je van tig verschillende developers allemaal plugins en andere zooi hebt geinstalleerd.

in principe is een cms het makkelijkste om te bouwen, voorkant van een site is een stuk pittiger.

Oh ja, briljant! Maakwerk adviseren voor zaken die ook met off-the-shelf oplossingen kunnen.

Dan zit die klant direct vast aan jou als leverancier, want geen ander bedrijf wil en kan die oplossing natuurlijk onderhouden (of het kost een vermogen om dat te doen, als het al mag in verband met copyrights.) En jij als leverancier blijft natuurlijk tot in lengte van jaren zorgen voor actief onderhoud toch? Jullie zorgen zelf voor security patches. Of wil je claimen dat jullie foutloos programmeerwerk afleveren?

Liever maatwerk in deze tijd dan off-the-self oplossingen die werkelijk ALLEMAAL zo lek als een mandje blijken te zijn. Bedrijf waar ik voor werk heeft een maatwerk CMS/Backend structuur en die is nog NOOIT gehacked is in 7 jaar. En als al een maatwerk applicatie in ontwikkeling hebt, dan kan je die altijd voor meerdere klanten inzetten. Jou maatwerk applicatie wordt dan ook een off-the-self oplossing.

En vanuit een bedrijfsperspectief is het wel handig om klanten aan je te binden. Of ben ik nu gek?

[Reactie gewijzigd door Ultimation op 16 oktober 2014 14:57]

Kanttekeningen:

• Jouw maatwerk is ook zo lek als een mandje.
• Hoe weet je zo zeker dat je nooit gehacked bent? Dat je het niet opgemerkt hebt betekent niet dat het niet gebeurd is.
• Dat je (mogelijk) niet gehacked bent komt omdat een maatwerk-oplossing hacken op zichzelf ook weer maatwerk is; meer werk voor weinig resultaat. Klinkt leuk, maar is zelfde categorie als security through obscurity.
• Wat gebeurt er met jouw maatwerk-oplossing als jullie bedrijf failliet gaat (of opeens geen zin meer heeft om het te onderhouden, of opeens de prijzen verdubbelt)? Niet jouw probleem, maar het kan zijn dat je klanten daar anders over denken...
• Dat jij als leverancier vendor lock-in wel ziet zitten, betekent nog niet dat afnemers er blij van worden. Er zitten voordelen en nadelen aan, dus het is (voor klanten) een afweging die ze moeten maken. Het is zeker mogelijk dat jullie potentiële klanten zijn misgelopen omdat je alleen maatwerk wilt leveren.

Kant-kanttekeningen:

• Dat ontken ik ook nergens.
• Als ik het niet weet kan ik het ook niet bevestigen. Dus ik kan zeggen dat wij nog nooit gehacked zijn.
• Met andere woorden, omdat het closed source maatwerk is het heel moeilijk te hacken. Op wat voor manier is dat slecht?
• Je moet zorgen dat je bedrijf niet failliet gaat.
• Als jij een goede leverancier bent vinden jou klanten een vendor lock-in niet erg. Waarom zouden ze naar een andere leverancier willen? Klanten die geen maatwerk willen hebben daar vaak ook geen budget voor. Dus dat is niet erg.

Er zit duidelijk geen ondernemer in jou.
Natuurlijk adviseer je maatwerk. Maatwerk heet niet voor niets zo. Je kan alles afstemmen naar de klant en security heb je geheel zelf in de hand.
Klant tevreden met het product en jij tevreden met een eventueel onderhoudscontract en de kosten voor het maatwerk.

Je kan niet leven in een wereld waarin alles gratis wordt gedaan voor je.

Ik ben inderdaad niet zo'n ondernemer, maar ik ben wel slim genoeg om me geen duur maatwerk aan te laten smeren als een simpeler, off-the-shelf oplossing ook zou voldoen. Het is voor de leverancier natuurlijk heel leuk, maar ik geef als klant liever mijn geld uit aan mijn core business, niet aan een site bouwer die meent alles beter te kunnen doen dan de teams achter Drupal of Wordpress.

het is maar hoe je het bekijkt en hoe het begroot wordt. zoals eerder gezegd: ik bizarre offertes gezien voor een "off-the-shelf" oplossingen, maar ook voor maatwerk oplossingen.

ik pretendeer niet dat ik beter ben dan een heel team drupal of wordpress, de vraag is meer of alle functionaliteit die in die paketten zit wel nodig is voor elke website.

Schijnbaar kunnen bouwers alles beter. Zo had het bij ons geen jaar geduurd voordat een kritiek lek in onze software gepatched zou worden.

En omdat veel mensen zoals jou denken worden die software pakketen veel gedownload en gebruikt en daarom veel aangevallen en gehacked waardoor ze weer in een slecht daglicht komen te staan. Waardoor jou bedrijf ook gezichtsverlies kan leiden wanneer jou website ineens allemaal rare IS achtige teksten laat zien.

Daarnaast, wat zou jij allemaal doen met bijvoorbeeld Wordpress? Een webshop van maken? Een CRM? Een voorraadbeheer systeem? Allemaal toepassingen waarvoor het allemaal niet bedoeld is?

[Reactie gewijzigd door Ultimation op 16 oktober 2014 17:22]

Ach, maatwerk blijft vaak jaren draaien zonder updates. Wordpress of Drupal daarentegen heeft zo gemiddeld elk jaar wel een kritieke update nodig om veilig te blijven. Dus als je die websites dan elke keer mag updaten van je klanten, dan verdien je weer wat extra als ondernemer. Dus zo kan je het ook bekijken...

(Al is het natuurlijk het beste als je een onderhoudscontract slijt voor je maatwerk apps die zo goed en veilig zijn dat je eigenlijk nooit wat hoeft te doen ).

Ik heb nu klanten die 7 jaar geleden een maatwerk website hebben (gewoon CMS en/of webshop) besteld en sinds 2 jaar ook bijvoorbeeld een Wordpress site hebben voor een nevenproject. Die worden opeens gehacked en ze vragen zich af wat er nou anders aan die websites is en waarom die wel een onderhoudscontract nodig hebben...

Tsja ik vind het zoals gezegd best lastig verkopen soms. Wordpress/Drupal kan redelijk snel opgeleverd worden dus goedkoop, maar heeft echt een onderhoudscontract nodig, dus dan ben je wel jaarlijks wat extra geld kwijt. Zo is het hoe ik het nu maar aan mijn (kleine) klanten vertel...

Alle tips welkom om dit in betere banen te leiden trouwens...

En als je dan de Wordpress of Drupal instanties van die klant mag updaten en alles gaat, zoals te verwachten, kapot. Heb je nog meer werk!

Klopt! Is altijd een heel gedoe! Vaak menu's en widgets weer helemaal opnieuw doen... En als de klant nou gewoon netjes betaalt, maar nee dat snappen ze dan weer even niet. Een hoop gezeur. Best een lastig af te bakenen business is het. Ik zal wel iets verkeerd doen...

Off-the-self toepassingen zijn anders vaak genoeg niet toereikend. Websites is nou eenmaal maatwerk, iedere omgeving is anders. Frameworks en libraries zijn natuurlijk prima, maar als iedereen kant-en-klaar oplossingen gaat draaien wordt het internet maar een dooie boel, en ab-so-luut niet veiliger.

Inderdaad. En daarbij, iets aanpassen in Drupal of Wordpress kostte mij altijd 4-8x zoveel tijd dan iets aanpassen in mijn eigen code. Lastig allemaal.

By the way: onok, is dat de vrouwelijke tegenhanger van odol? hahaha

jup

sja dit blijft de discussie.

maar goed even omdraaien: als jij allerlei custom modules bouwt voor een klant en hij moet updaten van drupal 7 naar drupal 8 ga jij dit neem ik aan ook niet gratis updaten.

Een custom module is van een andere orde aan hoeveelheid werk dan een compleet CMS, is het niet?

"Als je dat goed opzet"

Maatwerk is veel factoren duurder dan (C)OTS. Je eerste ontwikkel resultaten laten zeer lang op zicht wachten, tijd die je klanten niet hebben. Je klanten laten geloven dat in maatwerk geen dergelijke bugs kunnen / zullen zitten is flagrant liegen.

[Reactie gewijzigd door Yalopa op 16 oktober 2014 13:58]

De kans dat fouten misbruikt worden in maatwerksoftware is wel degelijk veel kleiner dan dat een fout wordt misbruikt in standaardsoftware, omdat iemand dan specifiek jouw website moet uitpluizen, terwijl voor standaardsoftware door hordes scriptkiddies geautomatiseerd het hele web wordt afgestruind naar ongepatchte sites.

Dat maatwerksoftware duurder is dan standaardsoftware is waar, maar als het belangrijk is dat je data niet in de verkeerde handen valt, zou ik persoonlijk niet vertrouwen op Drupal of Wordpress. Dat soort systemen wordt aan de lopende band gehackt.

Voor het gemak vergeet je dan even dat maatwerk ontwikkeld wordt op basis van frameworks & api's, draait op een webserver en gebruik maakt van een database en een OS... of maak je dat ook allemaal zelf?

Ik ben akkoord dat je niet blind moet vertrouwen op een systeem, maar als iemand binnen wil om data te stelen, dan zal een custom systeem het ze echt niet moeilijker maken.

[Reactie gewijzigd door Yalopa op 16 oktober 2014 15:39]

hoeft niet per definitie langer te duren, nogmaals: frontend is een stuk meer werk.
in de praktijk gaan de meeste klanten toch pas in het cms kijken als er aan de voorkant iets te zien is "anders hebben ze er weinig voorstelling van".

ik pretendeer niet dat ik 100% bugvrij ben, want dat is niemand idd, maar ik heb wel de controle over de code die ik oplever aan mn klanten en daar draag ik graag de verantwoordelijkheid voor. ik vind de trend van het klakkeloos themes en plugins installeren zonder controle zorgelijk: ik heb een tijdje bij een seo partij op kantoor gezeten die continu van alles aan het installeren waren en als het in elkaar draaide, kon ik er naar gaan kijken. voelde me dan net een vuilnisman.

ik heb sites opgeleverd die met maatwerk goedkoper begroot waren door mij dan een concurrent die wordpress wilde gebruiken. hangt dus helemaal af van jezelf. ik heb offertes tussen de 15 en 20k gezien voor een wp installatie met wat plugins dus tsja....

Niet langer?

De drupal / whatever CMS basics staan in een dag online achter een site. Hoeveel lijnen code klop jij per dag? Voor het gemaak vergeten we even dat maatwerk ook een zware analyse fase door moet. Ja, COTS heeft ook een analyse nodig maar het zal voor de meesten onder ons we duidelijk zijn dat deze minder balast heeft..

Okee, maar hoe jij dat dan met je maatwerk websites als je ineens allemaal PHP functies moet gaan herschrijven omdat ze bij een nieuwe versie niet meer ondersteudn worden? Of bijvoorbeeld een overstap van mysql naar mysqli en een tijdje later weer van mysqli naar PDO?

Ik vind dit lastig naar mijn klanten toe. Aan de ene kant willen ze weinig mogelijk geld uitgeven, dus dan is WordPress eigenlijk de enige optie. Maar een onderhoudscontract van 250 euro per jaar voor noodzakelijke updates (uitgaande van 4 uur werk) is dan ook weer teveel. Maar bij maatwerk ben ik dan vaak langer bezig dan 4 uurtjes om een CMS up te daten, soms wel 4 dagen. Dus ik vind dit altijd lastige materie. Ligt ook aan je klanten natuurlijk, een klein bedrijf vind al snel alles duur. Een groter bedrijf snapt het meestal wat beter.

Maatwerk voor een CMS? Alsjeblieft niet; voor elke security issue die in grote, ondersteunde CMSen opgelost worden, onstaan er tien 'maatwerk' CMSen omdat er blijkbaar onder PHP developers een ziekte heerst dat als ze het niet zelf gemaakt hebben het niet deugt.

Als je een PHP developer bent, en je denkt 'Ik ga mijn eigen framework / CMS maken want reasons', ga alsjeblief weg.

Ik kan jou stelling ook gewoon omdraaien.

Wanneer een bug in een groot CMS zit duurt het een jaar voor die eruit gepatched is. (zie artikel)

Als je een PHP developer bent en je denkt "Ik ga een kant-en-klaar CMS inzetten want reasons", ga alsjeblieft weg.

Wordpress en Magento zijn voor mensen die mooi kunnen designen.

Rustig aan jongen, vergaloppeer jezelf toch niet. Normaal lees ik dit soort discussies alleen en reageer ik niet maar nu wordt het me wat te gortig. Volgens mij overschat je je eigen vermogen om een complex Open Source framework te beoordelen op z'n tekortkomingen aan de hand van berichtgeving over een kritieke patch.

Ja, er zitten heus veel fouten in community contributed code. Maar door te doen alsof dat allemaal prut is gaat wel erg ver hè. Ik kan je verzekeren dat er zeer intelligente mensen in zowel de Drupal, Wordpress, Joomla als Magento community zitten. Niet 1, niet 5 maar honderden. Dus als jij, in je 1tje, of met een handvol (ex)collega's tot de conclusie bent gekomen dat een maatwerk oplossing voor jouw (niet "jou") klanten het beste is dan staat je dat vrij. Niemand die je daarin afvalt. Maar probeer dan ook een beetje respect op te brengen voor de mensen die tot de conclusie zijn komen dat samenwerken aan een groter project de beste keuze is.
Je hebt zelf nota bene een Wordpress blog, dus waar hebben we het over?

ok, doei...

Ligt er maar net aan wat je wil. Mensen willen allemaal bs features in een CMS tegenwoordig, dan is het logisch dat het bulky wordt. Ik vind zelf wordpress een prima systeem.

Maar elk stuk software wordt een draak als er willekeurige plugins in gaat installeren

Tja, daar heb je het probleem. Het moet alles kunnen en het liefst niks kosten.

En over Wordpress hoor ik nu juist vaak: "Tja, Wordpress wat moet je er van zeggen. Traag, onoverzichtelijk en een grote chaos aan modules", zeg maar wat jessy100 hierboven over Drupal schreef.

Wordpress heeft een klant van ons een aantal systemen in. Klant heeft ooit een thema gebruikt en aangepast waardoor het niet meer werkt vanaf PHP 5.4. Verder kan die klant alles binnen Wordpress en update plugins te laat of niet. Die WP site is al meer dan 30x gehackt... Gelukkig host ik dat systeem niet...

Het probleem met Wordpress is de manier waarop er mee om wordt gegaan. Met de juiste aanpak kan het systeem prachtig werken voor de bouw van sites, shops en dergelijke: Een slimme combi van maatwerk, nette eigen code en hier en daar een goed gekozen plugin indien nodig. Maar de insteek is meestal: standaard thema erin, 50 plugins erbij en dan alles grofweg wat aan elkaar hacken tot het werkt. Dat levert altijd rotzooi op, ongeacht het cms dat je kiest. Wordpress is te veel als "gemakkelijk" in de markt gezet, waardoor nu jan en alleman er van alles mee probeert te doen op zeer onprofessioneel niveau. Er kan vrij veel zonder zelf te programmeren, maar dat levert bij lange na niet hetzelfde op als wanneer een slimme WP-ontwikkelaar het bouwt.

Maar on-topic: Mooi dat deze bug in Drupal eindelijk is weggewerkt, en toch een beetje schandalig dat dit zo lang heeft kunnen bestaan.

[Reactie gewijzigd door geert1 op 16 oktober 2014 13:58]

Maar wat is een goedgekozen plug-in? Die klant had een plug-in met upload functionaliteit. (MailPoet newsletter plugin b.t.w.)

Deze plug-in is meer dan 1700000 keer gedownload en toch bleek deze plug-in lek te zijn. ( zie: http://blog.sucuri.net/20...t-wysija-newsletters.html )

Er werden rare PHP files geüpload met daarin:

eval(base64decode($_POST['blabla']))

De mailserver werd via dit script mooi misbruikt als spamserver en kwam op de blacklist van Google.

Het is vast allemaal tegen te gaan maar alleen voor mensen die er genoeg tijd in willen steken, technisch onderlegd zijn en het betreffende CMS met al haar plug-ins in de gaten houdt.

Wij hosten geen enkel standaard CMS systeem in elk geval. Als de klant het wil, verwijs ik ze wel naar een andere partij.

Een fout in een externe plugin kan inderdaad altijd voorkomen, ook al zijn ze zorgvuldig gekozen. Maar met een laag totaal aantal plugins wordt die kans wel verkleind en verder is het een kwestie van alles up-to-date houden of handmatig fouten oplossen. Ook in volledige maatwerksystemen kunnen gevaarlijke lekken opduiken natuurlijk, net als in de protocollen als SSL zelf; het blijft altijd voortschrijdend inzicht en bijsturen waar nodig.

Wat de grote, bekende CMSen aangaat, is het in elk geval een wereld van verschil op welke manier er mee om wordt gegaan. Het kan best behoorlijk veilige, nette resultaten opleveren, maar veel website-eigenaren die er zelf mee aan de slag gaan kunnen dat niet. En helaas zijn er ook genoeg webbureau's die wel de indruk wekken dat ze op hoog niveau werken maar dat niet daadwerkelijk doen. Zo ontstaat een beeld van Wordpress (en andere CMSen) dat er alleen maar amateuristische, onveilige resultaten uit kunnen komen en niets is minder waar.

Maar ik zei ook niet voor niets: "Het is vast allemaal tegen te gaan maar alleen voor mensen die er genoeg tijd in willen steken, technisch onderlegd zijn en het betreffende CMS met al haar plug-ins in de gaten houdt."

Maar dan blijkt een standaard CMS ook opeens duur te zijn en doen ze het liever zelf.... tja

Wij hosten geen enkel standaard CMS systeem in elk geval. Als de klant het wil, verwijs ik ze wel naar een andere partij.

En wat doe je dan wel, gewone php host?
Succes als het zo is, de gemiddelde php dev klopt veel slechtere code als wat je ziet in grote CMS'.

Php of .Net of zelf soms puur HTML, maar het zijn dermate kleine systeempjes, die hebben vaak niet eens een CMS.

De grote CMS-en worden in elk geval vele malen vaker aangevallen en gehacked.. En ik heb daar gewoon geen zin in.

Gelukkig zijn er genoeg partijen waar ik die mensen naartoe kan sturen.

Bedankt voor dit generaliseren. Ik wil je best eens wat code laten zien hoor.

Ja dat is precies het hele eieren eten. Rare, niets toevoegende functies toevoegen via schimmige, gare plugins of thema's gooit roet in het eten. Het is gewoon niet mogelijk om een degelijk CMS te maken wat je via plugins makkelijk kan customizen, zonder het open te zetten voor rommel

Dat geld volgensmij voor zo een beetje elk groot en populair systeem.

Maar ik denk dat die ervaring meer is bij mensen die weinig kennis hebben van drupal.
Als je zelf een systeem maakt is het vast sneller, maar drupal maakt het mogelijk om websites op te zetten zonder te hoeven programmeren. Als je daar weinig ervaring in hebt kan je een hele grote lompe website in elkaar klikken die zeer traag is.
Ik denk dat je dit met elk systeem wel voor elkaar weet te krijgen...

On topic:
Patches en fixen gaan inderdaad wel eens traag bij drupal, de communitie heeft steeds meer taken en doordat drupal zo populair is blijven er wel eens dingen liggen of worden ze vergeten.
Geen enkel systeem is perfect, maar ik denk dat het goed is dat drupal weer wat probeert te streven naar wat meer eenvoud (hopelijk wordt dat bereikt met drupal