Drupal waarschuwt voor ernstig beveiligingslek in Drupal 7 en 8

Het beveiligingsteam van Drupal waarschuwt beheerders van het cms dat het op 28 maart de details van een ernstige kwetsbaarheid bekend gaat maken. Het team denkt dat binnen enkele uren of dagen exploits kunnen verschijnen.

Het gaat om een ernstige kwetsbaarheid in Drupal-versies 7.x, 8.3.x, 8.4.x en 8.5.x, die volgende week woensdag tussen 18.00 en 18.30 bekendgemaakt wordt via onder andere de securitypagina van Drupal. Het beveiligingsteam adviseert beheerders op dat moment tijd vrij te maken om updates door te voeren, omdat exploits mogelijk binnen uren of dagen kunnen verschijnen.

De kwetsbaarheid is ernstig genoeg om specifiek voor 8.3.x- en 8.4.x-releases updates uit te brengen, hoewel het beveiligingsteam eigenlijk geen ondersteuning voor dit soort minor releases geeft, ook niet met beveiligingsupdates. Hoewel het team dit keer dus een uitzondering maakt, adviseert het aan beheerders ergens in de maand na het doorvoeren van de beveiligingsupdates naar de 8.5.x-release over te stappen.

Reacties (71)

Wel een heel erg informatief artikel moet ik zeggen (De link naar de security-pagina is verkeerd, trouwens.)

Edit: https://www.drupal.org/psa-2018-001 -- Thanks @Erwin94

[Reactie gewijzigd door RobinJ1995 op 22 maart 2018 17:48]

Het gaat hierom: https://www.drupal.org/psa-2018-001. Details van de nu gevonden vulnerability zijn nog niet vrijgegeven om te voorkomen dat er voor de update al een exploit beschikbaar komt.

In 2014 was er ook al een critcal lek in Drupal. Na het uitgeven van de update was er toen binnen een paar uur al een automated exploit in omloop, waarbij admin accounts konden worden aangemaakt op de websites.

[Reactie gewijzigd door Erwin94 op 22 maart 2018 18:11]

En de tijden kloppen niet:

"March 28th 2018 between 18:00 - 19:30 UTC"

Dus 20:00-21:30 CEST denk ik.

En dan dus 19:00 Nederlandse tijd? Dat is mooi kl#te, dat wordt dan op het werk eten om dan vervolgens de boel te updaten

Beetje vreemde gang van zaken? ze hebben een serieus beveiligings-probleem gevonden en gaan dat dan maar even (met aankondiging en al) op straat gooien? zou het niet handig zijn om meteen patches uit te rollen en de details nooit naar buiten te brengen?

Zal je zien dat de meest recente versie van Drupal opeens ads in de backend heeft toegevoegd ofzo, maar nee, je moet updaten 'want beveiligingslek', die ads zijn gewoon toeval

Ik weet geen betere manier eerlijk gezegd. Je kunt wel direct de patches online gooien maar juist patches zorgen doorgaans voor de exploit omdat iedereen dan meteen kan kijken wat het probleem was. Daardoor zouden sites dus meer risico lopen omdat niet iedereen maar even zonder aankondiging kan patchen.

Dan is de beste manier dus om te zorgen dat iedere beheerder vantevoren op de hoogte is dat er een patch aan zit te komen en de voorbereidingen treffen.

Ik weet geen veiliger manier dan hoe ze dit aanpakken.

Ze zouden het iets beter kunnen doen door een drie stappen plan te gebruiken:
1. Vandaag aankondigen dat er een patch komt voor een kritische bug.
2. Volgende week de patch uitbrengen.
3. Over 2 weken de beschrijving van de bug vrijgeven.
Natuurlijk kunnen mensen de bug herleiden uit de patch. Maar dit vertraagd het ontwikkelen van een exploit. Tevens is het beschrijven van de bug zeer nuttig zodat andere ontwikkelaars ervan kunnen leren en kunnen nagaan of misschien andere producten vergelijkbare problemen vertonen.

Dit is echt onzin. Dit gaat over een CMS, dus dit is echt geen exploit waar je onwijs veel moeite moet gaan doen om te kunnen exploiten. Ik weet zeker dat als je kennis van Drupal/PHP hebt je zo een exploit kan maken. Aangezien het in zowel Drupal 7 als 8 zit vermoed ik dat de exploit in legacy code zit uit Drupal 7.

Sterker nog, Drupal Security heeft op Twitter gemeld dat dit lek zelfs al in Drupal 6 zit: https://twitter.com/drupalsecurity/status/976828727048003585

dank, ik heb nog een klant die niet over wil bij meerdere waarschuwing. Maar er even een statische website van gemaakt met wget.

Klopt! Vreemd dat ze dit niet melden in de originele melding.
Misschien eens kijken welke code hetzelfde is gebleven tussen 6, 7 en 8. Kan nooit heel veel zijn.

Ik denk dat dan wellicht de boodschap 'update direct! ernstig probleem' verloren gaat.

Maar dat is nou net het hele probleem, drupal word (net als wordpress trouwens) her en der gebruikt voor 'actie sites' die niemand gaat updaten, dus een beetje slecht plan om notabene zelf op je eigen blog uit de doeken te doen wat er allemaal mis is, daar verlies je gewoon klanten mee.

Daar ben ik het beide niet mee eens:

1. Ja, men gaat tegenwoordig met websites om alsof het niets is. "Iedereen kan het zelf", niet? Nee. Veiligheid en privacy is al jaren een drama. Ook (non-technische-)beheerders van (actie-)sites behoren hier (wettelijk) zorgvuldig mee om te gaan. Dat het nauwelijks gebeurd is simpelweg onverantwoord. Mijns inziens moet er meer controle en handhaving plaatsvinden. Als de wettelijk gegronde boetes daadwerkelijk uitgedeeld worden dan is eindelijk dit "cowboy wild west"-beheer, met alle gevolgen van dien, voorbij,

2. Nee, het uit de doeken doen van een beveiligingsprobleem is niet een slecht plan. Mits dit verantwoordelijk gebeurt (patch beschikbaar & redelijk termijn om te updaten). Het is juist de "kop in het zand"-mentaliteit en de "schaamte" om problemen te bespreken welke het huidige digitale landschap teisteren. Security moet juist nu tijdens deze digitale revolutie direct bij de hoorns gepakt worden. Hoe langer we wachten met het veranderen van deze mentaliteit, hoe groter de problemen worden.

Maar dit is uiteraard slechts mijn mening.

Laat ik voorop stellen dat ik het volmondig met je eens ben dat beheerders verantwoordelijkheid moeten nemen (en eigenlijk je hele post) maar ik heb in het verleden zelf bij verschillende bedrijven van dat soort sites moeten maken, en echt niet dat er ook maar enige interesse is in een update beleid, zulke bedrijven willen gewoon x aantal sites per maand eruit trappen en verder boeit het ze niet. Zelfs als ik ze voor de neus houd dat ze lekker een maandelijks onderhouds contract kunnen afsluiten voor die een keer per jaar dat er een belangrijke update is, dat komt bij sales/marketing/baas alleen maar binnen als 'meer werk', nee 'dan verkopen we ze gewoon een nieuwe website' is het credo..

In het verleden heb ik nog wel eens (wp) sitejes geupdate in m'n eigen tijd, maar daar word ik ook een beetje te oud voor (mede met hoe in deze branch er vrijwel nergens overuren betaald worden etc) en ik vind het ondertussen ook minder mijn taak, juist door hoe verschillende bazen hierop reageerden heb ik nu zoiets van laat het maar fout gaan en dan kunnen ze het zelf oplossen. (zoals je wel kan raden werk ik dus ook niet meer voor zulk soort mensen)

Ook het uit de doeken doen van beveiligingsproblemen ben ik op zich wel voor, maar mede door hoe Drupal dus achter allerlij van dit soort sites hangt vind ik het een beetje slecht gepland, had dan minstens een maand na uitrollen van de patches gewacht ofzo, dat je de bedrijven/beheerders die wel willen in ieder geval een beetje tijd geeft, nou is het een kwestie van je moet die dag vrijmaken of maar accepteren dat je dan x aantal dagen onveilige sites hebt..

Je vergeet dat als Drupal de update zomaar op de wereld afschiet een hacker de update kan bekijken en het veiligheidsgat zomaar ziet.
Als Drupal dan niet eerder dit soort bericht de wereld heeft ingestuurd is het hek helemaal van de dam.

"In het verleden heb ik nog wel eens (wp) sitejes geupdate in m'n eigen tijd, maar daar word ik ook een beetje te oud voor (mede met hoe in deze branch er vrijwel nergens overuren betaald worden etc) en ik vind het ondertussen ook minder mijn taak, juist door hoe verschillende bazen hierop reageerden heb ik nu zoiets van laat het maar fout gaan en dan kunnen ze het zelf oplossen."

Ha, zo heel erg herkenbaar dit. Ik was een jaartje helemaal gestopt met het werken/updaten van WP en andere open source sites, precies om dit soort redenen. Ik gunde het mijn klanten niet meer dat ik voor ze zat te ploeteren (in eigen code effe een aanpassing maken gaat vaak 8x sneller dan in WP) en zij blijkbaar alles vanzelfsprekend vonden. En met WP en Drupal liep het altijd uit qua tijd, soms wel met een factor 4. Nu heb ik het toch voorzichtig weer opgepakt, maar dan alleen nog tegen uurtarief, dus geen fixed price meer vooraf, precies om dit soort dingen te voorkomen. Graag of niet!

Ik gun het de klanten wel dat ik hun sitejes bijhoud, maar het bedrijf wat ze de site verkocht had (waar ik niet meer werk) niet. Uitlopen qua tijd viel bij mij (95% WP) gelukkig altijd wel mee, ik had vrij snel een standaard pakket plugins wat ik erin gooide, en het was vaak meer werk een design om te zetten naar html dan het omzetten van die html naar een wp thema.

Al met al ben ik ook eigenlijk nog steeds wel voor systemen als Drupal en WP, maar het zou fijn zijn als de bedrijven die sites daarmee verkochten wat meer verantwoordelijkheid zouden nemen, en het zou helemaal fijn zijn als beide pakketten gewoon betaalde versies gingen aanbieden die actief getest worden op bugs & security issues.

En met WP en Drupal liep het altijd uit qua tijd, soms wel met een factor 4.

Even de opmerkingen in de release notes lezen en vervolgens 'drush up' doen, duurt niet lang hoor.

Ik bedoelde niet de tijd die nodig is om te updaten, maar om gewoon wat voor elkaar te krijgen met PHP. 'Even dit' of 'even dat' toevoegen met wat PHP-code aan bijvoorbeeld een navigatiemenu, ik noem maar een voorbeeld. Met maatwerk programmeer je dat er in enkele minuten in. Maar met WP moet je dan meer gaan doen (althans, ik ben er veel langer mee bezig altijd). En bij een volgende update van je theme is het dan weer weg, als je in de PHP-files zelf gaat lopen zitten (wat ook niet echt de bedoeling kan zijn). Maar ik zal me eens inlezen, kan nooit kwaad natuurlijk.

[Reactie gewijzigd door Anoniem: 426269 op 26 maart 2018 16:12]

Op die manier. Persoonlijk zou ik wel niet willen dat iemand (ikzelf of een derde partij) maatwerk PHP-aanpassingen doet aan de sites die ik beheer. Tenzij ze er natuurlijk voor zorgen dat ze die aanpassing in een module gieten en zorgen dat https://www.drupal.org/dr...ss-and-permissions-policy van toepassing is. Dat maakt alles een stuk makkelijker te onderhouden en veilig te houden.

Dat gaat wat geven!

Ik zal aan mijn computer zitten om een heleboel installaties te fixen. Maar hoeveel gebruikers zijn niet op de hoogte, duizenden slapende installaties en/of slapende beheerders, en zullen het dan misschien zitten hebben! Sommigen zullen het pas weken na de hack weten als hun host hun website in quarantaine zet. Hopelijk is het overroepen.

WordPress doet dat dan beter met auto-updates van de core. Hoewel ze bij WordPress 4.9.3 wel een steek laten vallen hebben en je manueel moet updaten naar 4.9.4. Dat zal ook nog een staartje krijgen vermoed ik.

Ik heb liever niet dat updates automatisch doorgevoerd worden. Stel dat er iets mis gaat en je ligt te slapen, ligt wel je website er een aantal uur uit ...

Voor Drupal gebruik ik drush om te updaten. Gewoon 1 commando uitvoeren: drush up.

Hebt ook natuurlijk nog zaken als mod_security voor apache welke wellicht op basis van regelsets het een en ander gaan blokkeren. Of CloudFlare en vergelijkbare diensten.

Ben het eens over de wijze van aankondiging. Wij zitten hierdoor klaar om op het moment van uitkomen direct voor al onze klanten met servicecontract dit uit te rollen. De rest van klanten waarvan we weten dat ze Drupal gebruiken informeren we over deze aankondiging. Voor hen de kans om ons of een eigen technische mensen hierop in te schakelen.

Ik heb een beveiligingsgat gevonden in je code.
Blijkbaar heb je nooit CVE-2016-9318 opgelost.

Verder gebruik je pbkdf2 terwijl bcrypt en argon2i toch echt de betere zijn.

An earlier version of Banshee has been audited by a Dutch IT security company. No issues were found.

Vraag me af hoe de eigenaar van security.nl heeft getest en in welk jaar, als ik binnen 1 minuut er al één vind.
Als dat in 2010 was is het verstandig die tekst te verwijderen.

» Your browser hides the referrer HTTP header line. You are therefor vulnerable for CSRF attacks via this website!

Nee, ik ben beveiligd tegen HTTP_REFERRER snooping door analytische bedrijven.
Heeft niks met CSRF te maken (Django maakt de zelfde fout).

Beweren dat je code veilig is, is de grootste fout die je kan maken.
Je mag wel zeggen dat je extra aandacht er aan besteed (als dat zo is).
Ik begrijp ook niet waarom nog bijna niemand signed PharData packages gebruikt

[Reactie gewijzigd door DJMaze op 23 maart 2018 01:43]

Ik heb een beveiligingsgat gevonden in je code.
Blijkbaar heb je nooit CVE-2016-9318 opgelost.

Laat maar een concrete exploit zien dan.

Verder gebruik je pbkdf2 terwijl bcrypt en argon2i toch echt de betere zijn.

Kraak pbkdf2 dan maar.

Vraag me af hoe de eigenaar van security.nl heeft getest en in welk jaar, als ik binnen 1 minuut er al één vind. Als dat in 2010 was is het verstandig die tekst te verwijderen.

Security.nl heeft jaren lang gedraaid zonder enige hack, maar met vele pogingen daartoe. Zo ook voor mijn websites.

Nee, ik ben beveiligd tegen HTTP_REFERRER snooping door analytische bedrijven.
Heeft niks met CSRF te maken (Django maakt de zelfde fout).

De referer werkte in het verleden prima. Maar inderdaad, de laatste tijd komt die header steeds meer onder druk te staan. Tijd voor een andere aanpak. Banshee heeft naast deze referer controle ook een token controle. Tijd om alleen die te gaan gebruiken.

Beweren dat je code veilig is, is de grootste fout die je kan maken.

Neuh. Mijn websites zijn namelijk nog nooit gehackt. Ook niet die op oude versies van Banshee draaien.

Je mag wel zeggen dat je extra aandacht er aan besteed (als dat zo is). Ik begrijp ook niet waarom nog bijna niemand signed PharData packages gebruikt

Omdat het gewoon niet handig werkt voor code die aangepast moet kunnen worden.

[...]

Laat maar een concrete exploit zien dan.

zoals hier beschreven staat:
Following the white Rabbit Down the SAML Code

[...]

Kraak pbkdf2 dan maar.

zoals Wikipedia
al aangeeft is het slechts een kwestie van dedicateed hardware of een mining rig. Ik heb deze niet liggen maar het is niet iets dat je nu nog als veilig kunt beschouwen voor persoonsgegevens.

[...]

Security.nl heeft jaren lang gedraaid zonder enige hack, maar met vele pogingen daartoe. Zo ook voor mijn websites.

Leuk, maar 1 het is niet controleerbaar (door ons) en 2 je hebt geen idee of hackers geen toegang hebben gekregen. je weet enkel dat jij niets hebt opgemerkt.

[...]

Neuh. Mijn websites zijn namelijk nog nooit gehackt. Ook niet die op oude versies van Banshee draaien.

Zelf claimen dat iets veilig is zonder (recent) onderzoek is nooit een goed idee. Security moet je bewijzen. dat jij nog niet iets hebt zien misgaan is geen bewijs. Ook kun je gewoonweg nooit iets over code veiligheid zeggen over je eigen code, omdat dit een "want, wij van WC-eend." argumentatie is. Iemand anders zal altijd dit moeten zeggen.

[...]
Omdat het gewoon niet handig werkt voor code die aangepast moet kunnen worden.

Omdat jij niet in staat bent om een fatsoenlijke bouw straat op te tuigen die verantwoord, veilig en kan omgaan met "secrets" zegt enkel iets over jouw kunnen niets over hoe "handig" editen van code is op live servers... (hint: dit is altijd een slecht idee)

[Reactie gewijzigd door Sysosmaster op 23 maart 2018 16:23]

Leuk die SAML link, maar dat gebruik ik niet. Je komt nog niet overtuigend over. Beetje stoer met een CVE strooien, maar je levert nul bewijs voor je claim.

Tuurlijk komen er steeds betere beveiligingszaken. Argon2 is er daar een van. Echter, pas in 7.2 is deze in PHP geimplementeerd. Maar daar gaat het eigenlijk niet om. Het gaat erom dat PBKDF2 voor nu sterk genoeg is.

Je claim dat ik niet zou merken als hackers mijn systeem binnendringen is nergens op gebaseerd. Die negeer ik dus verder.

En voor de rest: blijf lekker doorgaan met Drupal, Joomla, whatever. Happy patching volgende week. Ik ben dan lekker met leuke dingen bezig, wetende dat mijn websites veilig zijn. Veel succes met wachten op de volgende bug waar je mee aan de slag mag!

SAML (een systeem wat XML als transmissie taal gebruikt) is hier al vatbaar voor en is waar het is ontdekt. Als het in SAML werkt, werkt het in alle XML bestanden zeker als die verwerkt worden door de php applicatie. Je reactie is dus erg kortzichtig en getuigt van gebrek aan beveiligings ervaring.

zo ook je dat je negeert of hackers binnen komen.
Ik bedoel heb je überhaupt iets van een IDS?
Als dat zo is rep je er met geen woord over.
n met een IDS is het enigste dat je kan WETEN dat er iemand binnen (probeert) te komen. deze stopt nog niets. daar voor heb je toch echt iets als een IPS voor nodig.

Drupal heeft tenminste een Security team dat actief op zoekt is naar security problemen (en er ook voor betaald word). Ik geloof niet dat jij een team van ruim 30 man hebt die op ziek zijn naar problemen in jouw systeem.

Security updates horen bij alle goede applicaties, en je hoort gewoon een plan hiervoor klaar te hebben liggen.

Goed verhaal... maar het is je nog steeds niet gelukt om mijn websites te hacken.

Goed verhaal... maar het is je nog steeds niet gelukt om mijn websites te hacken.

Heb ik ook niet geprobeerd, aangezien ik al werk genoeg heb en jij mij niet hebt ingehuurd om dat te doen.

Ook mag dat niet zomaar wettelijk gezien.

Waar vraag je om bewijs?

Goed verhaal... maar het is je nog steeds niet gelukt om mijn websites te hacken.

is niet een vraag voor bewijs, het is een vraag om jouw website te hacken.

Bewijs was al geleverd door andere security experts die het probleem met SAML heben gevonden.

Tenzij jij hun verhaal niet snapt zie ik niet in waarom je blijft denken dat het er niet toe doet.

Ik zou zeggen probeer zelf eens uit of het kan in jouw systeem. IPV. hier tegen van alles aanschoppen zonder dat je eigen ervaring hebt in het veld.

Ik vermoed dat je jezelf bedoel maar om te laten zien hoe fout je zit pakken we de OWASP er bij over XXE.
https://www.owasp.org/ind...l_Entity_(XXE)_Processing

Specifiek de volgende regel:

An XML External Entity attack is a type of attack against an application that parses XML input. This attack occurs when XML input containing a reference to an external entity is processed by a weakly configured XML parser.

Ergo, dit is een type aanval waarbij er misbruik word gemaakt van hoe de XML parser werkt. en tenzij de parser zo is ingesteld om enkel een lokale DTD te gebruiken, (en een quick scan zag ik dat niet zo snel) en je wel van externe bronnen XML input accepteert (je API tester doet dit al) kun je gewoon de exploit gebruiken. Of te wel je kun een XML bestand maken dat een root kit payload load met root elevation welke je kernel infecteerd. zie jij niets van, en het haalt zichzelf uit de logs (dus daar staat ook al niets meer) en dan maar iedere bezoeker (behalve de beheerder die je geïdentificeerd hebt met de logs) een cryptominer sturen en ook de idle process vervangen door een crypto miner. Krijg de hacker lekker geld
en jij denkt nog steeds dat alles goed is.

Als je echt wat van security wist dan weet je dat alle professionals zeggen dat ze gehackt kunnen worden. en dat ze soft en hardware gebruiken om zich te beschermen in de ocntinue strijd die security heet.

En toevalig gebruikt xml.php een libxml parser waar hij expliciet dit gat open zet.
https://github.com/hsleis...ibraries/core/xml.php#L31
Zorg dus dat je nooit ergens code schrijft die externe XML inlaad.
Daarnaast zet je op alle websites dit open omdat het niet altijd thread-safe is.
https://bugs.php.net/bug.php?id=64938
Ik kan dus in theorie een side-attack uitvoeren als Banshee op shared hosting draait.
1. open Banshee website
2. open andere website met aangepaste XML data
3. andere website is gehackt dankzij Banshee

En verderop in de XSLTProcessor wordt extern laden ook niet dicht gezet met
setSecurityPrefs(XSL_SECPREF_READ_NETWORK);

Natuurlijk heeft zijn eigen code niet die tags in de XML. Maar... als je groot wordt, zoals alle anderen CMS'en, en mensen gaan modules/plugins maken en aanbieden.
Dan kom je ook in het nieuws als iemand iets stiekems heeft gedaan in een extensie (of extern) omdat jij dat niet dicht hebt gezet.

Nou kan je natuurlijk zeggen: maar dat kan diegene ook in de PHP code verstoppen.
Natuurlijk kan dat, alles kan. En dat is nou juist het probleem: zorg ervoor dat je niet beroemd wordt.

Vorig jaar nog een bedrijf op de vingers getikt dat SOAP gebruikte op de verkeerde manier en dus ook via LibXML gaten open zette (een PSP notabene).
En een andere PSP die vrolijk unserialize() en serialize() gebruikte in de communicatie

Maar goed, je vroeg niet via PB wat we tegen kwamen. Je ging trots in de aanval om ons voor gek te verklaren.
Nu is je exploit out in the open en kan iedereen hier mee aan de slag om websites te hacken (als ze het überhaupt zinnig vinden).
Dan heeft Drupal het nu toch iets beter aangepakt.
Die nemen gewoon elke melding serieus (of die nou klopt of niet).

[Reactie gewijzigd door DJMaze op 23 maart 2018 19:35]

van externe bronnen XML input accepteert (je API tester doet dit al)

Niet dus.

Nu is je exploit out in the open en kan iedereen hier mee aan de slag om websites te hacken

Ga je gang...

[Reactie gewijzigd door Faeron op 23 maart 2018 20:41]

In dat bericht staat toch echt duidelijk waar het probleem werkelijk zit.
Dat jij geen SAML gebruikt wil dus niet zeggen dat je geen probleem hebt.

De manier waarop XML gebruikt wordt in Banshee is heel anders dan hoe XXE werkt. Verdiep je voortaan dus eerst in de details voordat je iets gaat lopen roepen.

done

Security.nl heeft jaren lang gedraaid zonder enige hack, maar met vele pogingen daartoe. Zo ook voor mijn websites.
....
Neuh. Mijn websites zijn namelijk nog nooit gehackt. Ook niet die op oude versies van Banshee draaien.

Er draaien 1000+ websites met mijn CMS en zijn nog nooit gehackt.
En toch zitten er potentieel beveiligingsgaten in die websites.
Voor een blackhat is namelijk 1000 websites helemaal niet interessant, dat is veel tijd investeren aan een naald in de hooiberg met 0.00001% impact op het internet.
Je krijgt van mij een security report zodra je net zoveel websites host met Banshee als bijvoorbeeld WordPress, Joomla, Drupal of Typo3 dat doen.

Omdat het gewoon niet handig werkt voor code die aangepast moet kunnen worden.

Als je je code moet aanpassen per website, klopt er iets niet in je code.
Bij mij staat bijna alle PHP code in /usr/local/lib/php en kan niemand de code aanpassen.
Is ook helemaal niet interessant en ik update alle websites op een server in 1x.
Kan dan mooi bij een probleem dit isoleren tot 1 server.
Niks moet kunnen, het is een keuze die je maakt.

[Reactie gewijzigd door DJMaze op 23 maart 2018 12:02]

Ik heb geen ervaring met codes.

Maar de Portfolio heeft geen mobile Layouts? Tegenwoordig is dit een normale zaak.

Banshee heeft wel degelijk ondersteuning voor responsive design. Die paar sites uit de 'Showroom' die dat niet hebben, draaien nog op hele oude versies van Banshee.

Dank je.

Bij de WYSIWYG module zie ik alleen normale tekst, er moet nog wat extra's geinstalleerd worden zo te zien?

De CKEditor moet apart geinstalleerd worden. Die lever ik vanwege de omvang (net zo groot als Banshee zelf) niet standaard mee. Gebruik het script extra/download_ckeditor om bijvoorbeeld versie 4.9.0 te downloaden en te installeren.

[Reactie gewijzigd door Faeron op 23 maart 2018 12:31]

Hoe denk je dat jij in je eentje een veilig product kan maken?! Dat je daar zelf in gelooft

De claim is een beetje zo zo, maar het ziet er verder wel mooi uit. Fijn dat mensen zulke dingen maken en delen. Is wel iets meer waard als weer zo'n waardeloze -1 van weer zo'n ontzettende loser hier.
En Joomla (werk ik zelf mee) is geen rommel. Drupal ook niet trouwens.

[Reactie gewijzigd door MrMarcie op 22 maart 2018 22:49]

De claim lijkt mij erg dubieus op zijn minst. Ik zit uit interesse de code door te spitten want ik kan een frisse blik wel waarderen. Echter gaan bij mij de haren overeind staan op het moment dat iemand werkelijk alle standaarden en technieken aan zijn laars lapt en daarmee een full-featured CMS/Framework maakt. Ik wens @Faeron dan ook veel success maar om dan hier op deze manier een hobby project (spijt me zeer) aan te kondigen als veilig alternatief is toch wel wat te veel van het goede.

Om maar wat dingen te noemen:
- Geen gebruik maken van PSR-4 (of zelfs PSR-0)
- Geen tests
- Naamgeving die all over the place is
- Models dat eigenlijk repositories zijn
- Alles staat overal en nergens (een login script in models?)

En zo voort, kortom krijg ik het idee dat willens en wetens de kont tegen de krib is gegooid om het maar zelf te maken. Dit is prima voor leerdoeleinden maar ik hoop toch niet dat @Faeron de illusie heeft dat dit nou goed in elkaar zit.

@kipusoep heeft wel degelijk een goed argument.

Niet dat jij niet in staat bent om met weinig capaciteit een mooi systeem te bouwen maar wel of je de ondersteuning kan bieden aan de 100.000en websites die op je systeem draaien.
Dat is namelijk waar de Drupal community wel in staat is.

En ondanks dat er net als jouw systeem op Drupal voldoende aan te merken (stijl / standaarden) valt heb je stabiliteit nodig.

Over smaak, standaarden en techniek valt te twisten maar het valt en staat bij stabiliteit.

Drupal wordt meestal ingezet door grote partijen die tonnen aan euro's uitgeven aan een systeem. Daarmee willen zij ook zekerheden.
Dat betekend dat ze niet afhankelijk willen zijn van de grillen van 1 ontwikkelende partij. Ook willen ze juridisch alles netjes in orde hebben en afgedekt hebben en het kunnen verantwoorden naar buiten toe.
Dat is waar een grote community aan bijdraagt.

De Drupal community doet dat ook niet. Het is niet alsof die community mij gaat helpen bij problemen met mijn Drupal website. Er wordt hoogstens een patch uitgebracht voor een bug, maar dat zou ik ook doen.

Er valt weinig 'juridisch netjes in orde te hebben' bij gratis open source software.

Jij heb dit nog nooit geprobeerd of wel?
de Drupal gemeenschap (op bijvoorbeeld Chat.drupal.nl) zal je echt wel verder proberen te helpen mits je inzet toont. Ook als je naar evenementen gaat word er vrijelijk veel informatie uitgewisseld over verschillende oplossingen.

Ook zijn de issue queues van de diverse modules erg actief, en worden problemen vaak gewoon samen aangepakt.

En juridisch op orde is niet zo moeilijk als je GPL compliant code oplevert.

Acquia geeft zelfs (tegen betaling) garanties af over de Drupal code.

[Reactie gewijzigd door Sysosmaster op 23 maart 2018 21:25]

Hoe dan ook zal er geen overheidsinstelling met houw CMS in zee gaan.

De community is ontzettend waardevol en juist dat is de kracht van open source.

Tot dat jij het tegendeel bewijst blijf ik bij Drupal.

Hoe dan ook zal er geen overheidsinstelling met houw CMS in zee gaan.

Zeker weten?

Ik denk dat niemand die Security (of de GDPR / AVG ) ter harte neemt “Banshee PHP CMS“ overweegt in de huidige vorm. Het is gewooon niet compliment en het voldoet niet aan basale eisen rondom veiligheid, onderhoudbaar en wettelijke kaders.

Wettelijke kaders?!? Niet alle plantjes uit je tuin zijn goed om te roken, wist je dat al?

Onder welke steen leef jij als je je niet druk maakt over de AVG

Dingen als de datakluis. Recht om vergeten te worden. Alle toegang tot persoonsgegevens loggen.
3 dingen waar jouw applicatie niet op voorbereid is.

Je kletst weer als een kip zonder kop.

Ik zou je adviseren om een gesprekje met Arnoud Engelfriet te maken.
Als iT jurist weet hij beter dan ik wat de wettelijke kaders zijn.

Al bij al lijkt het risico beperkt tot het inzien van comments indien je comments hebt geactiveerd en de hacker toegang gekregen heeft om comments te maken.

Users with permission to post comments are able to view content and comments they do not have access to, and are also able to add comments to this content.

This vulnerability is mitigated by the fact that the comment system must be enabled and the attacker must have permission to post comments.

Je quote komt van de vorige update SA-CORE-2018-001 van 21 Februari.
De update waar voor wordt gewaarschuwd psa-2018-001, daar zijn op dit moment nog geen details van bekent. Dat weten we pas 28 Maart.

Foutje in de link, staat een komma achter.

Ik beheer 3 drupal sites, twee van mezelf en een van mijn vrouw.
Is het slim om deze sites net voor de aankondiging offline te zetten?

Via de offline modus in drupal zelf of een andere manier? (plesk?)

Ik moet niet proberen meteen die avond de update te doen, dat gaat gegarandeerd mis, ik wil het de volgende morgen doen.

Je kan beter een .htpasswd aanmaken en de .htaccess aanpassen zodat de website achter een http login zit. (kan volgens mij ook in Plesk).
En dan haal je die de volgende dag weg als je hebt geupdatet

Omdat we nog niet weten wat het probleem is kun je het beste de hele website offline halen tot we weten wat het is en je dus kan inschatten of "offline" modus van drupal voldoende bescherming bied tegen het euvel. een htpasswd kan ook werken helaas ben je echter beperkt in je wachtwoord lengte in is dit dus niet een lange termijns oplossing.

Dank mannen!

Ze wachten wel tot het laatste moment met het uitbrengen van die update
Lekker, zit je dan te wachten in de avonduurtjes. Met één site waar ik niet goed bij kan, want firewall en teamviewer die het laat afweten. Hopelijk is onderhoudsmodus voor nu afdoende.