Cookies op Tweakers

Tweakers is onderdeel van DPG Media en maakt gebruik van cookies, JavaScript en vergelijkbare technologie om je onder andere een optimale gebruikerservaring te bieden. Ook kan Tweakers hierdoor het gedrag van bezoekers vastleggen en analyseren. Door gebruik te maken van deze website, of door op 'Cookies accepteren' te klikken, geef je toestemming voor het gebruik van cookies. Wil je meer informatie over cookies en hoe ze worden gebruikt? Bekijk dan ons cookiebeleid.

Meer informatie

Tientallen websites van de overheid hebben openbaar toegankelijke admin-pagina's

Tientallen websites van de Nederlandse overheid voldoen niet aan overheidsrichtlijnen, omdat beheerpagina's makkelijk te vinden zijn en omdat deze publiek toegankelijk zijn. De richtlijnen schrijven voor dat inlogpagina's niet aan publieke sites gekoppeld zouden moeten worden.

Het gaat om tientallen sites van onder meer de Belastingdienst, verschillende GGD's, een tiental gemeenten, vijf veiligheidsregio's, acht omgevingsdiensten en enkele waterschappen. Doordat deze beheerpagina's makkelijk te vinden zijn, zijn ze doelwit voor kwaadwillenden, schrijft Trouw op basis van eigen onderzoek. Dat hangt wel af van de mate van beveiliging van de inlogpagina's, maar daarover trekt Trouw geen conclusies.

De websites voldoen niet aan richtlijnen die het Nationaal Cyber Security Centrum in 2014 voorstelde voor overheidswebsites. Die richtlijnen adviseren om openbare pagina's en beheerderspagina's strikt te scheiden. Dat gebeurt te weinig, concludeert Trouw.

Dat zegt niet dat de sites per definitie ook makkelijk binnen te komen zijn, ze kunnen nog steeds voorzien zijn van een sterk wachtwoord of andere inlogbeveiliging, maar omdat de pagina's openbaar vindbaar zijn, kunnen anderen toegang proberen te krijgen tot de beheerderspagina's.

Alle websites die Trouw als kwetsbaar categoriseert, maken gebruik van WordPress als content-managementsysteem. Volgens internetspecialist Jules Ernst, die Trouw bij het onderzoek hielp, maken 164 overheidsites gebruik van WordPress. WordPress is vanwege zijn populariteit een veelgekraakt platform en er zitten regelmatig kwetsbaarheden in plug-ins. Zo werd deze week nog een beveiligingsupdate geforceerd voor Jetpack. Sinds 2014 waarschuwt het NCSC voor 36 ernstige veiligheidsproblemen met WordPress, zegt Trouw.

Wat vind je van dit artikel?

Geef je mening in het Geachte Redactie-forum.

Door Stephan Vegelien

Redacteur

09-06-2021 • 08:09

141 Linkedin

Submitter: juliank

Reacties (141)

Wijzig sortering
Ik vind het wel vreemd dat het onderzoek zich vooral lijkt te richten (paywall, kan het originele artikel niet lezen) op WordPress-installaties. Ja dat CMS is berucht om zijn beveiligingslekken, maar als je het hebt over externe toegang tot CMS-inlogpagina's kan het net zo goed om andere CMS'en gaan. Dit kan ook gebeuren bij Drupal, Typo3 of Umbraco (deze CMS'en worden bij veel overheden gebruikt).
Volgens het artikel gaat het erom dat overheden Wordpress gebruiken (er wordt in het artikel gesteld dat overheden waarschijnlijk geen Wordpress mogen gebruiken van de BIO, zonder nadere toelichting).
Mógen overheden WordPress gebruiken? Dat lijkt onwaarschijnlijk als je de Bio leest, de Baseline Informatiebeveiliging Overheid die voor het Rijk, gemeenten, provincies en waterschappen geldt. Het biedt een lange lijst met voorschriften. Meestal wat abstract (‘zorg voor goed beleid’), soms ook concreter (‘zorg voor sterke wachtwoorden’).
Daarnaast staat er dat deze websites inlogpagina's hebben die publiek beschikbaar zijn. Nou is dat laatste niet per se een goed idee, maar ook weer niet een gigantisch probleem. In een pentest rapport zou ik dit als een laag risico bestempelen, en het gebruik van Wordpress in zijn geheel niet als een beveiligingsrisico benoemen.

Sensatie verhaal van beveiligingsbedrijven die graag hun naam in de krant willen hebben staan. De Persgroep heeft zich mooi voor hun karretje weten te spannen.
In een pentest rapport zou ik dit als een laag risico bestempelen, en het gebruik van Wordpress in zijn geheel niet als een beveiligingsrisico benoemen.
Dan zal ik mijn pentests maar liever niet door kipppertje B.V. laten doen. Beveiliging is altijd een afweging die je maakt tussen risico, mogelijke gevolgen en eventueel ongemak. Voor een gemiddelde weblog zou ik een publiekelijke loginpagina niet als kritisch bestempelen, maar het gaat hier over websites van de overheid!

Je hebt als overheid de verantwoordelijkheid om alle burgers veilig toegang te bieden tot informatie. In dit geval is het risico hoog (veel bezochte websites toegankelijk voor iedereen), de gevolgen van een hack rampzalig (overheids website besmet 150.000 inwoners met ransomware) en het eventueel ongemak miniem (login met IP-whitelist en natuurlijk fail2ban).

Laten we het over WP maar even niet hebben (oh, nou doe ik het toch). Het is een uit z'n krachten gegroeid blogplatform dat NIET geschikt is voor professionele websites. Alleen al het feit dat elke zolderkamercowboy plugins kan schrijven en publiceren. Daarnaast barst het van de "bedrijfjes" die aan de lopende band wordpress sites in elkaar flanzen voor een prikkie. Daar moet je je als overheid helemaal niet mee inlaten.

Ter illustratie de waarschuwing die Gentoo Linux geeft na het installeren van WP uit de repositories:
!!!!!!!!! SECURITY WARNING !!!!!!!!!!!

Wordpress has had a history of serious security flaws. Any application
with less widespread use but the same amount of security issues would
have been removed from the tree.

After a short period of being in the unstable tree we once again decided
that we hard mask the package.

THIS MEANS THAT THERE IS NO GUARANTEE WHATSOEVER THAT THE PACKAGE WILL
GET UPGRADED WITHIN A REASONABLE AMOUNT OF TIME EVEN IN THE CASE OF
SEVERE SECURITY ISSUES.

We consider installing this package a severe risk to your system and
you should keep a close eye on the common security trackers so
that you are able to fix problems with your installation yourself if
required.
Uiteraard installeer je een CMS nooit als package, maar alleen de eerste alinea zegt al meer dan genoeg.
Bedankt voor je mening, maar als beveiligingsexpert denk ik het in dit geval beter te weten.
Met een pentest meet je het technische risico, onderbouwd met bewijs. Het maakt in die zin niet uit of het een website is van een bank, of een hobby website. Waar jij over spreekt is het business risico (en die is natuurlijk heel anders voor een bank website). Deze vertaling moet worden gedaan door de business.

Technische risico's worden doorgaans gemeten m.b.v. CVSS (https://www.first.org/cvss/calculator/3.1). Vereiste hierin is dat je een daadwerkelijk uitbuitbare kwetsbaarheid hebt. Als je het open hebben staan van een inlogpagina zou willen scoren, dan zou je bij CVSS 3.1 uitkomen op 0.0 (Geen risico, CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:N). In het geval van Wordpress zou ik desondanks toch een bevinding aanmaken omdat je het aanvalsoppervlak onnodig groot hebt gelaten, maar technisch gezien is het geen vulnerability.

En wat Wordpress als vulnerability betreft, wij proberen zoveel mogelijk ons op feiten te baseren en niet op onderbuikgevoelens. Oftewel: POC or STFU. Los daarvan: ik heb aardig wat websites van de overheid getest, en doorgaans zijn de Wordpress-achtigen de minst interessante websites, zoals websites waar alleen nieuws of informatie staat.
....maar technisch gezien is het geen vulnerability
En dat is nou precies mijn punt. Bij beveiliging gaat het nooit om één aspect of invalshoek. In de praktijk maakt het namelijk wel degelijk uit of of een loginpagina toegankelijk is voor publiek. Sterker nog, het maakt zelfs verschil of die loginpagina van Drupal is, Wordpress, of een of ander zelfgeschreven dingetje.

Dan heb je nog het onderliggende systeem (IIS, Apache, Lighthttpd, NginX) en verdere maatregelen die zijn getroffen om het veiliger te maken (2Fa, fail2ban, require ip, enz.). Allemaal zaken die je met een pentest niet meet, maar er wel degelijk toe doen.

Kortom, een pentest is maar een heel klein onderdeeltje van een serieuze audit op beveiliging. Net als dat het slagen van de unittests niet garandeert dat de code bug vrij is.
In het geval van Wordpress zou ik desondanks toch een bevinding aanmaken omdat je het aanvalsoppervlak onnodig groot hebt gelaten, maar technisch gezien is het geen vulnerability.
Hier ook weer; technisch gezien is niet genoeg. Wordpress is inmens populair en werkt als een magneet op kwaadwillenden. Kijk maar eens in de logs van een willekeurige website. Ik garandeer je dat die volstaan met ".../web/wp-login.php' not found or unable to stat...". Dat is geen onderbuikgevoel. Dat is hard bewijs. Dat is je POC. Ik beheer zelf een stuk of zes webservers met meer dan 100 websites. Geen daarvan is in wordpress gebouwd, toch staan de logs vol met wp-login.php.
Los daarvan: ik heb aardig wat websites van de overheid getest, en doorgaans zijn de Wordpress-achtigen de minst interessante websites, zoals websites waar alleen nieuws of informatie staat.
Het is volstrekt irrelevant wat de inhoud van zo'n website is. Als een aanvaller er in slaagt om zo'n website te compromitteren, zijn bezoekers in gevaar. Dat kan een overheid zich echt niet permiteren.
Vooropgesteld: ik ben geen fan van WP en ben blij dat ik er al jaren praktisch niet meer mee te maken heb.

Evengoed wil ik hier wel even vaststellen dat je nogal forse kritiek uit terwijl je ook aangeeft dat je eigenlijk geen serieuze ervaring hebt met WP.

Je kan ieder CMS veranderen in gatenkaas door de beveiliging om zeep te helpen. De drempel om dat voor elkaar te krijgen met WP is vrij laag, zeker. Dat sluit echter niet uit dat je WP ook veilig kan maken door allerlei maatregelen te nemen. Doordat WP zo populair is, ook onder hackers, is er ook nogal wat aandacht voor beveiligingsoplossingen.
Evengoed wil ik hier wel even vaststellen dat je nogal forse kritiek uit terwijl je ook aangeeft dat je eigenlijk geen serieuze ervaring hebt met WP.
Hmm, ik ben al ruim twintig jaar webontwikkelaar en ik heb ontelbare WP-sites gebouwd en zelf plugins geschreven. Ik ben alleen ook server beheerder en ik weet wat er in mijn logs staat.
Je kan ieder CMS veranderen in gatenkaas door de beveiliging om zeep te helpen. De drempel om dat voor elkaar te krijgen met WP is vrij laag, zeker. Dat sluit echter niet uit dat je WP ook veilig kan maken door allerlei maatregelen te nemen.
Het probleem met WP is dat als je er een beetje een leuke website van wilt maken, dat je allerhande plugins nodig hebt. Ook voor beveiliging (akismet, wp-fail2ban, bla bla). Die plugins zijn echter altijd door een derde partij gemaakt en dus niet of slecht controleerbaar. In tegenstelling tot bijv. Drupal die een security advisory policy heeft waar ook veel ad-ons onder vallen.
Laten we het over WP maar even niet hebben (oh, nou doe ik het toch). Het is een uit z'n krachten gegroeid blogplatform dat NIET geschikt is voor professionele websites.
Interessante mening – of moet ik zeggen flame bait? – maar de realiteit is dat er veel meer professionele websites wel dan niet op draaien. Om niet te zeggen dat het dé standaard is.

De inlogpagina van een WP kan gewoon aangepast worden, kan geblokkeerd worden op basis van whitelist / IP-adres etc dus alles wat een ander systeem kan, kan ook met Wordpress.

Wat betreft goedkope bedrijfjes.. Dééd onze gemeente dat maar. Maar nee, zoiets moet volgens allerlei bizarre regels aanbesteed worden. Regels zoals ‘meedingen kan alleen als u aan kunt tonen ruime ervaring met vergelijkbare overheden te hebben’. Hoezo Catch 22? Kortom een paar peperdure bureau’s pikken alle gemeentelijke websites in en rekenen daar de hoofdprijs voor. Niet vier maar vijf cijfers voor de komma voor een simpele CMS en dat is uiteraard exclusief huisstijl-ontwerp.
Interessante mening – of moet ik zeggen flame bait?
Dat is niet een mening, maar een constatering. Niet omdat Drupal nou zo geweldig is, maar even ter vergelijking:

https://cve.mitre.org/cgi-bin/cvekey.cgi?keyword=wordpress
https://cve.mitre.org/cgi-bin/cvekey.cgi?keyword=drupal
– maar de realiteit is dat er veel meer professionele websites wel dan niet op draaien. Om niet te zeggen dat het dé standaard is.
Wordpress wordt veel gebruikt, maar dat er "meer professionele website wel dan niet op draaien" lijkt me wat ver gaan. Hun marktaandeel op CMS-gebied is ongeveer 60%, maar dat zijn echt niet allemaal professionele websites.
De inlogpagina van een WP kan gewoon aangepast worden, kan geblokkeerd worden op basis van whitelist / IP-adres etc dus alles wat een ander systeem kan, kan ook met Wordpress.
Dat klopt, maar dat neemt nog niet weg dat er op de plugins voor WP geen enkele gecentraliseerde controle plaatsvind en het onderliggende systeem toch echt letterlijk een uit z'n krachten gegroeid blogsysteem is. Die waarschuwing van Gentoo staat er echt niet voor niets.
Wordpress has had a history of serious security flaws.
[…]
Die waarschuwing van Gentoo staat er echt niet voor niets.
Het is (te) makkelijk om het populairste systeem af te raden, want dan kun je achteraf altijd zeggen: Je was gewaarschuwd in de meeste gevallen. Maar daar heeft niemand die een cms nodig heeft iets aan.

Elk cms heeft zijn voors en tegens. Beveiliging is belangrijk, maar gebruikersgemak net zo goed. Niemand heeft iets aan een veilige, maar onbruikbare website.

Dat constant wordt geprobeerd in te loggen bij elke site op /wp-admin.php, /administrator (joomla), domain.com?q=user/login (drupal) etc etc, is sinds jaar en dag een gegeven. Dat gebeurt net zo hard met elk ander cms.
Ik geef je groot gelijk! Het gaat hier dan ook niet over Jantje die over zijn kat blogt of Mientje die haar origamiwerkjes ten toon stelt. Die moeten vooral gewoon WP blijven gebruiken. Voor de overheid ligt dat wat mij betreft wel een beetje anders.
Dat constant wordt geprobeerd in te loggen bij elke site op /wp-admin.php, /administrator (joomla), domain.com?q=user/login (drupal) etc etc, is sinds jaar en dag een gegeven. Dat gebeurt net zo hard met elk ander cms.
En daar moet ik je ongelijk in geven. Dat gebeurd zeker niet "net zo hard" met elk ander CMS. WP is een gewild target. Veel meer dan joomla of Drupal of welk ander CMS dan ook.

[Reactie gewijzigd door delphium op 9 juni 2021 14:15]

Voordeel van Wordpress als package installeren is wel dat de code hard op read-only kan worden gezet. Dat gaat je niet lukken als je de ingebouwde Wordpress updater gebruikt. Vermoedelijk voorkom je daar al een hoop ellende mee...
Ah kudos.

De gemiddelde cloud (lees bijv. Office 365, Google Cloud, Amazon AWS, goh, wie gebruiken dat nu toch helemaal, alleen MKB uiteraard) heeft ook complete beheer interfaces aan het internet hangen.

Als het niet lek is en niemand lekt credentials, niet bepaald een probleem.

Als het wel lek is, blijkt via openbare pagina's ook nogal eens het een en ander te kunnen. Heb je die beheer interface niet eens nodig.

Waarheid is vrij dubieus in deze...
De Pers Groep (eigenaar van Tweakers en Trouw) zou het vast niet grappig vinden als ik hier link naar een addon waarmee paywalls kunnen worden omzeild... maar weet dus dat die browser add-ons bestaan.

Wat betreft Wordpress valt het wel mee zo te zien:
Internetspecialist Jules Ernst onderzoekt welke software overheden gebruiken. Van de 1148 websites van de Rijksoverheid die hij op afstand kan uitlezen, gebruiken er 165 WordPress.
Als ik beide artikels doorga (art 1, art 2) dan wordt er wel onnodig veel aandacht gelegd op Wordpress, terwijl er vervolgens wordt gesproken over ontbrekende richtlijnen, en zwak nageleefde procedures.

Gelukkig heeft de overheid op andere punten wel het licht gezien:
Is het niet beter als de overheid zelf een systeem bedenkt om veilige, overzichtelijke webpagina’s te publiceren? De woordvoerder van IBD gelooft van niet. “Dan ga je ervan uit dat de computercode geen enkele zwakke plek of fout zou bevatten, en een foutloze code bestaat niet.”
Gelukkig, want anders zouden we over 10 jaar met allemaal verouderde maatwerk overheidswebsites zitten.
hier link naar een addon waarmee paywalls kunnen worden omzeild
Dan moet dit maar server en niet client side gebeuren...
Het feit dat je inderdaad vanaf een client de beveiliging kunt ontlopen, laat inderdaad zien dat er wat fundamentele fouten in het hele paywall systeem zitten. Als je de code leest van de paywall-omzeil-addon dan zie je hoe slecht het hele systeem überhaupt is.
if (matchDomain(['parool.nl', 'trouw.nl', 'volkskrant.nl', 'demorgen.be', 'humo.be'])) {
document.addEventListener('DOMContentLoaded', () => {
const topBanner = document.querySelector('div[data-temptation-position="PAGE_TOP"]');
const paywall = document.querySelector('div[data-temptation-position="ARTICLE_BOTTOM"]');
const hiddenSection = document.querySelector('div[data-temptation-position="ARTICLE_INLINE"]');
const overlay = document.querySelector('div[data-temptation-position="PAGE_BOTTOM"]');
removeDOMElement(topBanner, paywall, hiddenSection, overlay);
});
}
Andere websites zijn soms iets slimmer... die plaatsen een cookie met een page-view counter. Gelukkig kun je nooit je eigen cookies weggooien 8)7

Edit. Uitdaging aan de Tweakers ontwikkelaars om iets te bouwen dat wel werkt ;)

Edit 2. Doet me ook een beetje denken aan de hele YouTube-dl rel. Als beveiliging zo kinderlijk eenvoudig is om te omzeilen, dan is het omzeilen ook niet meer een misdrijf. Wel grappig eigenlijk om zo te bespreken. Trouw haalt terecht aan dat sommige overheidswebsites nogal wankele beveiliging hebben, maar 10 regels JavaScript is genoeg om hun businessmodel onderuit te trekken.

[Reactie gewijzigd door Eonfge op 9 juni 2021 09:49]

Jij noemt het "fundamentele fouten", maar het punt is dat de site toch íets van content moet presenteren aan zoekmachines om goed geïndexeerd te worden. Dus je krijgt de titel en een paragraaf of twee aan tekst te zien, en daar overheen een paar HTML-elementen die doen alsof er meer tekst op de pagina staat.

En dan zijn er vast browser-plugins die die overlays kunnen weghalen, maar dat betekent niet dat een paywall onzin is en dat je met zulke plugins ineens alles kunt lezen.

Als je met je betaalde account ingelogd bent, is het artikel langer. Niet altijd, ik weet niet of het bij dit specifieke artikel opgaat, maar dit is verre van een "fundamentele fout": het is juist fundamenteel hoe het web werkt.

Edit: oh, wow, Trouw toont en verbergt gewoon de volledige artikeltekst, divs met de klasse artstyle__text staan op display: none. Ik moet beamen dat dit neigt naar "fundamenteel fout". :+

[Reactie gewijzigd door CodeCaster op 9 juni 2021 10:12]

Wat ook een leuke truc is, is het misbruiken van ?referral-links. Als bijvoorbeeld Geenstijl een artikel van de Trouw op hun website gebruikt, dan zit daar een sponsor-tag aan. Deze zou je in theorie op elk willekeurig artikel kunnen gebruiken. Mooi voor Geenstijl want die krijgen geld, handig voor jou want met die ?referral kun je ook direct het artikel inzien.
Dat is alleen fundamenteel fout als je denkt dat het doel van paywalls is om 'absoluut' te zijn.

Paywalls zijn vergelijkbaar met een slot op je fiets (of je voordeur, for that matter)

Een slot op je fiets zal een beetje dedicated fietsendief niet tegenhouden. De vertraging van sloten wordt meestal gemeten in minuten dat het kost om ze te openen. Een fietsslot dat 2 minuten vertraagd is al heel wat.

Verder kun je de fiets meenemen (of de voordeur intrappen).

De veiligheid van een slot is dus niet absoluut. Maar het dient wel een heel belangrijk doel: het onderstreept het maatschappelijk contract. Om iets mee te nemen, danwel naar binnen te lopen zul je moeite moeten doen. Het maakt het begaan van de daad een veel bewustere keuze.

Idem voor paywalls. De krant is niet geinteresseerd in absoluut afschermen, ze willen vooral onderstrepen aan de lezer dat hun produkt een waarde heeft. Door een beetje weg te geven en de gebruiker een beetje moeite te laten doen, hopen ze zo mensen over te halen om een abonnement te nemen.

Bij de meeste paywalls is het een kwestie van je cookies weggooien en klaar. Maar met die aktie bevestig je wel dat het waarde voor je heeft.

Zolang er maar een bepaalde hoeveelheid conversie is, is het zakelijke doel van de paywall al behaald.

Sterker nog, er is een kans dat wanneer je 100% werking hebt, dan er dan lagere conversie is: ik heb bijvoorbeeld een jaar lang een bepaalde krant gelezen met die cookie-truc, totdat ik bij mezelf bedacht: ik lees wel heel veel artikelen, laat ik maar eens dit medium ook betalen.

Met een 100% muur was ik allang naar een andere site gegaan en was ik nooit naar een betaalde abonnee omgezet.
De vertraging van sloten wordt meestal gemeten in minuten dat het kost om ze te openen. Een fietsslot dat 2 minuten vertraagd is al heel wat.
Maar hoe meet men dit dan? Want dit lijkt me in hoge mate afhankelijk van het gereedschap en de handigheid van de fietsendief. En wat heb je aan een slot als je fiets alsnog in 1 seconde meegenomen kan worden in een busje.

[Reactie gewijzigd door breakers op 9 juni 2021 11:24]

Dat laatste is precies het punt: een paywall danwel slot is niet bedoeld als 100% blokkade.

[iets minder on-topic]
Over die tijdsmeting heb ik me ook wel eens achter de oren gekrabt. Na wat Googlen kom je dan van slotenmakers via keuringsbureaus uit bij een NEN-norm: https://www.nen.nl/nen-en-15496-2008-en-119423

En die zit, ironisch genoeg, achter een betaalmuur.

Mijn gedachte is dat het domweg is dat ze kijken hoe lang het duurt om er met de slijptol doorheen te gaan, maar er zal wel iets meer bij komen kijken.

[edit]
Juiste NEN-norm bijgevoegd. Fietsslot ipv. gevelslot.

[edit2]
Oh, er is wel een inkijkexemplaar met een inhoudsopgave: https://www.nen.nl/norm/pdf/preview/document/119423/

Vanaf hoofdstuk 6.5 gaan ze de leuke dingen doen :D. Dus inderdaad allemaal wat gestandaardiseerd geweld erop loslaten en daaruit komt dan zo'n minutenwaarde.

[Reactie gewijzigd door Keypunchie op 9 juni 2021 12:56]

Bedankt voor het opzoeken :)
Dat laatste is precies het punt: een paywall danwel slot is niet bedoeld als 100% blokkade.
Dat begreep ik al wel, ja. Ik kijk zelf wel eens domweg in de html, die ene keer dat ik een artikeltje niet mag lezen zonder abonnement. Vaak kun je het daar al gewoon alsnog lezen. En anders staat het vaak ook wel op een andere site.
Haha, de zegen van de naïviteit.

Drie keer raden waar de meeste bezoeken vandaan komen: zoekmachines en social media.
Drie keer raden wat er gebeurt wanneer je die content blokkeert aan de kant van de server. Precies, je raakt je volledige SEO positie kwijt en daarmee je belangrijkste bron van bezoekers.

Vervolgens maken bedrijven (die wél weten wat ze doen) een afweging en denken ze dus dat het het meest voordelig is om de content client-side te blokkeren, het handje vol rebellen (dat zichzelf ontzettend intelligent vindt) door de vingers te zien en vooral meer reguliere bezoekers aan te trekken die wél bereid zijn om te betalen.
Doet me ook een beetje denken aan de hele YouTube-dl rel. Als beveiliging zo kinderlijk eenvoudig is om te omzeilen.

Ondertussen is youtube music ook overbodig, met een account kun je je eigen music playlists maken en afspelen want alle muziek staat gratis op youtube.
Moet je wel de youtube non-stop extentie downloaden want anders word je video op pauze gegooit met de vraag of je verder wilt kijken.
Ik was het net ook eens aan het doorlezen.
Nog een kanttekening: wat al 5+ jaar werkt op nieuwssites van België is naar de thumbnail gaan van een krant preview, rechtermuisknop, link aanpassen (meestal een hoger aantal is de volgende pagina) en de dimensions verhogen (dat je de resolutie verhoogt).
Is al talloze keren gemeld geweest door verschillende mensen, maar ze kiezen ervoor om het niet te fixen omdat het makkelijker/goedkoper is om een DMCA uit te sturen naar sites die het publiek misbruiken dan hun brakke CDN’s eens te fixen 🤷‍♂️

[Reactie gewijzigd door miyapow156 op 9 juni 2021 10:05]

Dat gebeurt ook bij het artikel van Trouw. Zover ik zie, geeft de backend alleen maar de titel terug en niet de daadwerkelijke inhoud.

Dit soort addons werken dus alleen bij websites die een paywall hebben door middel van een generieke/custom javascript plugin. Steeds meer websites hebben de paywall in de backend geïmplementeerd, hier kom je dus gewoon niet omheen met een of andere plugin.
Zoek eens op 'bypass paywall extension', dan vind je een browser-extensie die ook de artikelen van Trouw gewoon 'bypassed'.
Even een ander citaat uit dit artikel.
Eind mei meldde NCSC bijvoorbeeld over WordPress dat een kwaadwillende op afstand willekeurige computercodes kan uitproberen en zo mogelijk toegang krijgt tot gevoelige informatie. Websitebouwers moeten na zo’n melding razendsnel een nieuwe versie van de software installeren, om hackers een stap voor te blijven. Patchen heet dat, de boel oplappen. Dat heeft veel weg van symptoombestrijding.
Andere systemen hoeven blijkbaar niet gepatcht te worden volgens Trouw.
Thanks geïnstalleerd, hopen dat het ook gaat werken voor de "Plus" artikelen van Tweakers.
Vaak kan je via incognito mode, de paywall gewoon omzeilen.
Ik kan helaas het bericht van Trouw zelf niet lezen, maar is het onderzoek daadwerkelijk zo slecht? Ze zullen toch op zijn minst iets van WPScan tegen die websites aangehoord hebben om problemen te detecteren, toch?

Natuurlijk is het bestaan van een login pagina geen beveiligingslek. Wat een bizarre suggestie zou dat zijn. Misschien wil je een IP-filter voor de systeemlogin hebben, maar als je systeem kwetsbaar is zodra dat filter iets doorlaat, heb je wel heel erg gefaald als beheerder. Alsof de wp-adminpagina het lek is waar criminelen door binnenkomen, zo'n website hack je door een of andere vage plugin die door een beunhaas geschreven is uit te buiten.

[Reactie gewijzigd door GertMenkel op 9 juni 2021 08:58]

Het gaat hier om overheidssystemen. En hoewel de aanwezigheid van een login pagina niet meteen een probleem hoeft te zijn is het bezien vanuit hun positie (vertrouw ons, wij gaan goed met je data om) ook niet het meest handige. Kleine moeite om die admin loginpagina helemaal onzichtbaar te maken voor iedereen die er niet perse hoeft te zijn.

En elke drempel die je opwerpt is weer een drempel die een aanvaller moet nemen. Makkelijke fix en de wereld is weer een stukje veiliger.

Blijkbaar heten die pagina's ook nog wp-admin, want anders hadden ze deze niet zo gemakkelijk gevonden. Dit en het feit dat er blijkbaar geen IP blok op die pagina zit, zou je wel kunnen doen afvragen hoe het met de rest van de beveiliging is gesteld. Deze eerste bevindingen wekken niet meteen veel vertrouwen.
Tja, het ligt er maar net aan wat voor website het precies is. Aangezien er gemeentes zijn die officiële Facebook-pagina's als naslagwerk lijken te beschouwen, vind ik een WordPress-pagina voor veel overheidsdingen niet zo erg.

Als gemeente Schubbekutteveen hun vergaderingen op een WordPress-pagina uploaden en het daarmee af is, vind ik het niet zo erg eigenlijk. Ook heb je erg veel overheidsinstellingen die alleen maar aan informatievoorziening doen, dan is WordPress best een goede keuze eigenlijk. Het is altijd beter dan een publieke aanbesteding naar Capgemini waar een stel stagaires een bloggingplatform in elkaar beunen dat na vijf jaar van ellende uit elkaar valt.

Een loginpagina onzichtbaar maken kan best een uitdaging zijn, helemaal met de geldtekorten waar veel overheidsinstellingen mee kampen. Iemand inhuren om ieder systeem na te gaan en goed te configureren kost al snel een hele bak met geld, en vanwege de aanbestedingsregels kom je al snel uit bij degene die het minste geld voor de minste service vraagt.

Ik vind dat de situatie moet worden verbeterd, maar van alle problemen die ik met overheids-ICT kan hebben, is "de WordPress-login staat op /wp-admin/" wel de slechtste om aan de kaak te stellen. Dit voelt als zo'n mailtje dat iedere websitebeheerder wel eens ontvangt van iemand die een "kwetsbaarheid" heeft gevonden door een automatische scanner te laten draaien op hun website en dat automatisch gegenereerde rapport blind doorstuurt om bug bounties te sprokkelen.

Ik vind de sensationele manier van schrijven die Trouw hier gebruikt erger dan de configuratiefout van de overheid, eigenlijk. Na daadwerkelijk serieuze datalekken en hacks (GGD, Hof van Twente, etc.) met zoiets uit de bus komen is goedkoop scoren bij lezers. Ze komen met grote claims over dat de overheid gehackt kan worden, leggen de nadruk op 36 kwetsbaarheden sinds 2014, terwijl dat natuurlijk niets is voor een platform dat zo complex is, en ze doen alsof iedere hacker zomaar een loginscherm kan omzeilen:
Zij bieden een publieke webpagina aan, waarin je een gebruikersnaam en wachtwoord moet invullen om de website over te nemen. Die pagina is zo te vinden. Hackers hebben technische middelen om een gebruikersnaam te achterhalen en geautomatiseerd wachtwoorden uit te proberen, totdat ze beethebben.
Ik kan ook een artikel schrijven over Trouw op deze wijze. Trouw heeft hun voordeur aan een parkeerplaats zonder slagboom. Autobestuurders kunnen het terrein zo op. De zijkant van hun pand is voorzien van glas om indringers tegen te gaan, maar inbrekers hebben gereedschap om hier gaten in te maken en zo het pand binnen te dringen. Jopie Wilgraagookeenkeerindekrant van beveiligingsbedrijf HekDicht vindt het "opmerkelijk en gevaarlijk" dat deze slagboom op de parkeerplaats ontbreekt. Inbraakonderzoeker Agathe Eersteagentinonsadresboek geeft aan dat het inderdaad voorkomt dat inbrekers glas kapotmaken om zich toegang tot een gebouw te verschaffen. Als inbrekers eenmaal toegang hebben, kunnen ze alle computers en opslagmedia waarop vertrouwelijke documenten en mogelijk zelfs de identiteiten van hun ondergedoken perscontacten staan. Karel Post van de krantenunie zegt dat het niet de bedoeling is dat mensen zonder toestemming het gebouw betreden.

Ja, ik vind dat de overheid dit beter moet doen, maar nee, ik vind het de ophef niet waard. Tweakers noemt het zelf ook een "publiek toegangelijke admin-pagina", terwijl alleen het loginscherm publiek toegankelijk is; om bij de adminpagina te komen, moet je eerst nog een stap verder.
Helemaal met je eens dat er ergere dingen in de wereld zijn dan dit "probleem". Echter zit de overheid met een fiks imagoprobleem als het op beveiliging van onze gegevens aankomt. Een eerste stap, als blijk van goede wil en daadkracht, zou wel eens iets simpels als dit kunnen zijn.

de map wp-admin onzichtbaar maken voor niet bevoegden is best wel simpel, En dat is wat ik probeerde te betogen. Als dat simpele al wordt nagelaten, dan kun je je afvragen hoe het er bij de complexere beveiligingszaken aan toe gaat.
DIt is "laaghangend fruit".

Je checkt websites op het bestaan van /wp-admin/ en schrijft vervolgens een opzienbarend artikel over hoe onveilig het allemaal wel niet is. Terwijl mensen die er echt verstand van hebben weten dat het niet per se een probleem hoeft te zijn.

Goedkope journalistiek.
Ik denk dat in het verslaggeving en discussie een beetje te veel wordt gefocussed op de vraag of een site "lek" is of niet. Daar gaat het niet om. Het gaat om de vraag of de overheid haar eigen richtlijnen volgt want die richtlijnen (van het NCSC) zeggen dat zo'n inlogpagina onverstandig is.

Een aantal mensen hebben al opgemerkt dat de aanwezigheid van een aanmeldpagina niet echt een fout is. Toch zegt het wel iets. De beste beheerders en systemen die ik ken doen allemaal iets om zo'n inlogpagina extra te beveiligen zodat het publiek er niet bij kan of deze zelfs helemaal weg te halen.
De besten gebruiken centrale Single Sign On systemen en zijn bezig met passwordless logins, bv op grond van certificaten of hardware token.

Zo'n omgeving heb je alleen als je een en ander goed onder controle hebt en weet wat je doegt. Als je ergens op de markt een simpel websitje laat maken door de laagste bieder dan kun je dat soort features wel vergeten. Dan krijg je wachtwoorden als Welkom2020.

Daar komt bij dat, zoals iedere ervaren IT'er weet, de kans vrij groot is dat zo'n pagina niet goed beheerd wordt. Er worden regelmatig flinke gaten gevonden in Wordpress (net als alle andere software) en dus zelfs als het nu veilig is dan kan dat over een jaar weer heel anders zijn en zo'n login-pagina blijft een aantrekkelijk doelwit.

De login pagina is overigens niet eens de ergste pagina om publiek te hebben staan. Er is ook nog zoiets als 'xmlrpc.php'. Dat is een pagina die bedoeld is om geautomatiseerd met Wordpress te communiceren en helaas zijn daar ook veel beveilingsproblemen mee geweest. In tegenstelling tot zo'n login-pagina heeft zo'n xmlrpc.php geen enkel nut voor 99% van de sites. Het advies is al jaren om die te blokkeren. Als die nog open staat is dat een sterke aanwijzing dat die site niet van het hoogste beveiligingsniveau is.

Dus het hebben van een inlog-pagina is niet direct een probleem, maar het zegt wel iets over de achterliggende organisatie. Een organisatie met minder inlogpagina's dan een andere (vergelijkbare) organisatie heeft waarschijnlijk een veiligere omgeving.

We kunnen op grond van dit onderzoek niet zeggen of de overheid het goed of slecht doet in verhouding tot anderen. Maar we kunnen wel concluderen dat ze zich niet allemaal houden aan de richtlijnen.
Dat is helaas een open deur, maar soms moet je ook de open deuren onderzoeken om ze op de kaart te krijgen.
Ik snap niet hoe een systeembeheerder nog "welkom2020" als wachtwoord kan gebruiken voor een admin account.

Dan kan je jezelf toch niet serieus meer nemen...
Sterker nog, WordPress standaard waarschuwt als het wachtwoord te zwak is, en zal zelf al een sterker wachtwoord voorstellen.

Je moet tegenwoordig zelfs een checkbox aanvinken wil je een zwakker wachtwoord dan aanbevolen gebruiken.

Dus, ik weet niet of dat hier is gebeurd, maar indien die beheerder willens en wetens standaard beveiligingsprotocollen van WordPress omzeilt op een productiewebsite dan is daar mogelijk sprake van nalatigheid

Ik weet niet wat WordPress dan nog kan doen, misschien dat er eerst autorisatie van hoger af binnen de organisatie moet komen om het wachtwoord te wijzigen, maar daar kan het ook mis gaan

Kortom, als je de sleutels in de auto laat zitten, omdat het makkelijker is, tja, moet je niet verbaasd zijn als die wordt gejat, in dat geval betaald de verzekering ook niet uit meen ik, als je geen sleutels kan aantonen
En via een plugin kun je redelijk triviaal 2FA toevoegen.
Meeste grote webhosters die ik ken installeren bovendien al standaard een login beschermingsplugin bij het installeren van WordPress. Dit om bijvoorbeeld de hoeveelheid logins achter elkaar te beschermen en te blocken indien nodig. Waarbij tevens melding naar beheerder gestuurd wordt indien nodig

Los van de tal van andere beveiligingsmogelijkheden en zakelijke beheer opties

Elk systeem kent zijn kwetsbaarheden, helaas, maar dit klinkt gewoon als onprofessioneel.

Zoals meerdere hebben geopperd, hoog tijd voor een IT ministerie, die centraal dit soort dingen kan aansturen bijvoorbeeld. Dat zou de beveiliging ten goede kunnen komen
Maar MH$#de2DOD65BN3*Yl8ff# is zo lastig om op te schrijven/aan de telefoon door te geven/te typen :+
1WachwoordIsNietZoMoeilijkDoeErMaar2!
Beter te onthouden, maar natuurlijk gevoelig voor de betere dictionary attacks.
Wat is het verschil tussen:
  • "Een wachtwoord is niet zo moeilijk"
  • "Doe er maar 2!"
en
  • "That's a battery staple"
  • "Correct!"
Verplichte kost: https://xkcd.com/936
Dan ga je nu al de mist in want jij bedoeld wachtwoord maar typt wachwoord :+
En maar vloeken dat je wachtwoord niet werkt :9
Het verbaasd me hoe weinig mensen (zowel persoonlijk als zakelijk) password managers gebruiken. Het is ook gewoon beter en handiger.
Begrijp ik ook nooit, maar ik vermoed dat dezelfde psychologie hier van toepassing is als je zo vaak ziet: Dan moet je je een keer een uurtje verdiepen in welke / hoe je een password manager installeert en gebruikt. Tja en 'daar heb ik nu geen tijd voor / zin in'. Ook al zijn ze meer tijd kwijt aan vergeten wachtwoorden, maar dan in kleinere stukjes.

Net zoals 10 van de 10 mensen een nieuw apparaat, app, gereedschap etc gewoon uitproberen en pas gefrustreerd de handleiding gaan lezen als het al 10 minuten niet lukt.
uhh, je kan toch gewoon sterke readable wachtwoorden maken?
Of desnoods passphrases? Zo moeilijk hoeft dat helemaal niet te zijn.
Ik zie je :+, maar als hij opgeschreven of over de telefoon is doorgegeven is het al ongeldig.
Maar MH$#de2DOD65BN3*Yl8ff# is zo lastig om op te schrijven/aan de telefoon door te geven/te typen :+
Ik zie je smiley maar het is toch een terechte opmerking. Dat is een probleem waar mensen last van hebben en problemen worden opgelost. Waar het fout gaat is dat ze het zelf gaan proberen op te lossen in plaats van een professional in te schakelen waardoor ze niet beseffen dat het al drie stappen eerder fout ging, namelijk bij het bouwen/inrichten van de software en de processen er om heen.

Wachtwoorden of telefonisch doorgeven zou je moeten voorkomen. Als je ze dan toch moet doorgeven dan moet je op z'n minst een veilig communicatiemiddel gebruiken en het telefoonnetwerk is dat niet.
Ook voor het opschrijven van een wachtwoord zou nooit een goede reden moeten zijn.
Wachtwoorden kopieer je, met de hand overschrijven is maar foutgevoelig. Bij het voor het eerst instellen van een wachtwoord laat je het genereren door de computer, dat is veel beter dan er op vertrouwen dat mensen zelf goede wachtwoorden bedenken of dat je wachtwoordregels daar echt invloed op hebben.

En eigenlijk vind ik dat we helemaal van moeilijke wachtwoorden af moeten. Goede wachtwoorden kunnen mensen toch niet onthouden. Dus dan moet je het door de computer laten doen, bv via een password manager. Als we het werk dan toch aan de computer overlaten kunnen we wel iets beters doen, bijvoorbeeld met digitale sleutels/certificaten.

Overigens ben ik niet helemaal tegen wachtwoorden. Met makkelijke wachtwoorden heb ik geen probleem. Mijn pinpas beveilig ik met een wachtwoord van 4 tekens en dat zijn nog allemaal cijfers ook!
Het verschil is natuurlijk dat die pincode niet de enige beveiliging is, je moet ten eerste al de pinpas in handen hebben. De volgende beveiliging is dat je pinpas wordt geblokkeerd als je te vaak een verkeerde code invoert.
Wachtwoorden kunnen dus nog steeds een plek hebben in beveiligingssystemen maar ze moeten niet de hoofdrol hebben.
die leven echt niet in 2021 8)7
Klopt want ze zijn met dit wachtwoord gehackt in 2020.

[Reactie gewijzigd door francoski op 9 juni 2021 08:29]

Ieder jaar een nieuw wachtwoord.
Dat is eerder een strategie voor het geval iemand stiekem met je account inlogt en om de schade te beperken. Het is verder prima, maar het zorgt niet voor veiligere wachtwoorden (welkom2020, welkom2021, etc). Schijnveiligheid.

Doe dan sterke password policies (gemeten in bits, niet hoofdletters/nummers/speciale tekens etc), 2FA, en meldingen bij nieuwe logins op onbekende apparaten.
Grote kans dat dat soort systeembeheerders ook gewoon hier op Tweakers rondhangen. Onze collega's dus. Misschien zijn dat soort luie wachtwoorden (en andere slechte configuraties) juist wel veroorzaakt omdat ze op tweakers rondhangen....
Bij de loodgieter thuis lekt de kraan.
Tja geen training.
Dan is er iemand die bedacht heeft dat er een mooie site moet komen, betalen dan 120.000 euro voor een Wordpress site, maar wie moet dat dan onderhouden? Truus van de administratie had een leuk stukje geschreven voor de schoolkrant van haar zoon. En die wordt dan gevraagd om in te loggen en nieuws te schrijven/plaatsen. Dat moeilijke wachtwoord was ze meteen vergeten, maar met reset wachtwoord heeft ze er wat makkelijk te onthouden iets van gemaakt.t

[Reactie gewijzigd door Automark op 9 juni 2021 08:49]

Ja, en nu heeft ze – helemaal zelf bedacht! – hetzelfde wachtwoord voor al haar logins }> super handig!
Niet alleen voor Admin accounts, gewoon NOOIT!
Ook niet als initieel wachtwoord voor een nieuwe gebruiker.
Wie dat doet, mogen ze direct inzetten bij de plantsoendienst.
bij ons worden wachtwoorden in AD die moeten worden gereset automatisch voorzien van RNG-generated password die de eindgebruiker via End-2-End encrypted url kan opvragen(desnoods via zn telefoon).
Onze helpdesk medewerkers krijgen deze wachtwoorden niet in te zien.
Hmm, heb je informatie over hoe dat gedaan word?
Powershell. Maar helaas mag ik de oplossing/code niet delen.
Klinkt al een stuk beter inderdaad! ;)
En helemaal hoe jullie ze ophalen!

En een password generator, ik snap dus niet dat bedrijven die niet standaard aan zetten in plaats van Welkom.... ;)
Zo durf ik zelfs te stellen dat vanuit beveiligingsoogpunt je ook gebruikers namen wilt die niet tot een persoon te herleiden zijn. Wie de hoge functies heeft is wel te vinden vaak, de gebruikers naam kun je vaak raden, zit daar een zwak password op: BINGO!
password die de eindgebruiker via End-2-End encrypted url kan opvragen(desnoods via zn telefoon).
Hoe controleer je of die eindgebruiker ook daadwerkelijk is wie hij/zij zegt dat hij/zij is?
Als het wachtwoord is gereset heb je immers geen geauthoriseerde gebruiker aan de lijn.

Zo'n password portal met vragen waarbij iedereen al lang is vergeten wat ie ooit geantwoord heeft, of van die vragen die vele anderen ook kunnen invullen. (vragen als: wat voor merk was je eerste auto, wat is je favouriete smaak ijs)
de gebruiker moet als hij in dienst komt een wachtwoord mondeling doorgeven(soort van recovery wachtwoord) aan de helpdeskmedewerker. Die voert dat wachtwoord in en dan wordt de link met het nieuwe wachtwoord gestuurd naar het privé mailadres van de gebruiker.

*edit*
Maar dit systeem gaat vervangen worden door een authenticator. Welke weet ik niet, maar ze zijn bezig om het recovery wachtwoord te vervangen voor softtokens.

[Reactie gewijzigd door equit1986 op 9 juni 2021 12:29]

Dan gaan de plantsoentjes in NL er binnenkort allemaal keurig netjes uitzien!
En de IT infra zal er ook op vooruit gaan ;)
Prutsers hebben we in deze sector niet nodig.
Naar de plantsoenendienst lijkt mij slecht voor die afdeling. De plantsoenendienst moet ook geen last krijgen van personeel dat niet netjes werkt. :o

Zelf zie ik ze liever naar parkeerbeheer gaan, dat geeft ons tweakers nog enige uitdaging. }>
Nieuwe gebruikers zouden niet eens een initieel wachtwoord toegekend moeten krijgen, maar self-service registratie. En natuurlijk moet elke werkgever een goede password manager en dergelijke regelen. Geen "as a service" meuk waar alles bij een Amerikaans bedrijf opgeslagen wordt, iets dat lokaal draait. En natuurlijk 2fa verplicht stellen, yuikeys of smartcards en dergelijke.
Goed idee. Mag ik vragen hoe groot jullie organisatie is, hoe het gesteld is met digitale vaardigheden van de gebruikers en welke on-prem password manager jullie alle gebruikers aanbieden en verplichten te gebruiken?

Dit is een serieuze vraag, want wij zijn op zoek naar zo’n oplossing voor 1000+ gebruikers (dus met user management via AD) die weinig affiniteit met ICT hebben en liefst schriftjes gebruiken.
Ik heb diverse relaties gevraagd, maar vrijwel niemand gebruikt een password manager op het werk, of gebruikt een van de bekende (buitenlandse) Cloud diensten.

We zijn nu bezig met marktverkenning, dus als je concrete tips hebt o.b.v. praktijkervaring, houd ik mij sterk aanbevolen!
Ik heb onlangs alle wachtwoorden aangepast naar !0202mokleW

Lekker random, en voldoet aan de vereisten
Lokaal IT bedrijfje maakt website voor de gemeente, levert deze op en zegt nog: "dit zijn de login gegevens, wel veranderen hé!"
Vervolgens krijgt een ambtenaar diezelfde gegevens in handen gedrukt in de site in te gaan richten.
Systeembeheerder? Welke systeembeheerder? Site hoeft niet self hosted te zijn he
Die lopen een jaar achter met hun security updates O-)
Ik zou eerst serieus afvragen waarom een artikel een voorbeeld van een ftp server gebruikt om kennelijk iets te beweren over hoe onveilig een cms is. Dat het veiliger kan wil nog niet zeggen dat er zwakke wachtwoorden gebruikt worden.
Wordpress is ook helemaal niet geschikt voor grote enterprise- en overheidswebsites.
Wordpress is ook helemaal niet geschikt voor grote enterprise- en overheidswebsites.
Nu niet. Maar wat ik zou eisen is dat de overheid een bijdrage levert aan deze platformen om ze veilig te maken. Ik denk dan aan een donatie, of een overheidsdienst met programmeurs die opensource projecten versterkt (die projecten waar de overheid/maatschappij op leunt, zoals WP, encryptie suites, etc etc). Niet mijn voorkeur, maar een soort tussenvorm zou zijn dat ze dit uitbesteden aan een van de leveranciers.

[Reactie gewijzigd door Dooxed op 9 juni 2021 08:36]

Overheid maakt nu vooral gebruik van het commerciele Amerikaanse Bloomreach CMS.
"De Overheid" bestaat niet. Het is een verzameling instanties en organisaties die allemaal hun eigen keuzes maken op dit gebied. Ik heb best wel veel overheidswebsites getest, maar ik ben Bloomreach nog niet tegen gekomen, hoewel ik meteen van je aanneem dat er overheidsorganisaties zijn die het gebruiken. De meeste grote CMS'en worden wel door een overheid gebruikt.

[Reactie gewijzigd door kipppertje op 9 juni 2021 11:56]

Hangt van de toepassing af. Niet alles bij enterprises en overheden is extreem groot. Als je een al dan tijdelijke site nodig hebt voor een deel van de medewerkers kan Wordpress een prima oplossing zijn.
Ik kan je het nog sterker vertellen, Wordpress kan in sommige situaties ook een stuk voordeliger zijn en beter werken dan gespecialiseerd enterprise software. Moeten we de nieuwe mijn.belastingdienst.nl in Wordpress bouwen dan? Absoluut niet! Maar de interne website waarop medewerkers kunnen aangeven wat ze als lunch willen? Ja tuurlijk. Onzin om daar een enterprise CMS voor te gebruiken met torenhoge licentie kosten en bijkomende complexiteit.
Dat was misschien voeger zo maar nu zijn er bedrijven die daar in specialiseren met extra werk en configuratie.

Wordpress zelf kan erg veilig geïnstalleerd worden en de veiligheidsproblemen zitten niet in wordpress zelf maar in slechte plugins

[Reactie gewijzigd door Justice op 9 juni 2021 08:46]

Ligt er geheel aan hoe dit aangepakt wordt. WordPress kan juist heel goed ingezet worden voor grote en veilige websites, maar niet door zomaar een developer die eventjes de documentatie gelezen heeft, want dan heb je gevaarlijke plugins als Jetpack die je performance onmogelijk schaalbaar maken en weer een extra ingang forceren (via de XML-RPC, die je juist helemaal uit wil zetten voor grotere websites).

Ik heb een tijdje voor een heel groot internationaal development bureau gewerkt waar we veel met WordPress deden, hoewel het niet mijn keus was heb ik wel heel veel geleerd over hoe je een WordPress-installatie kunt beveiligen en hoe je performance op grotere websites garandeert. Het is te doen, maar er zijn wel wat extra stappen nodig.

Overigens zegt het publiek zijn van de inlogpagina daar heel weinig over, wat veel belangrijker is is of die pagina's met een gebruikersnaam en wachtwoord te gebruiken zijn of er 2FA afgedwongen wordt.
Had liever een product gezien dat out of the box solide is, dat is nu neit het geval. Qua performence is WP wel bagger te noemen. Je moet tot in den treure het zaakje optimaliseren, cache plugins zoals WP Rocket erop zetten, moet je niet willen.

In 2021 zou ik voor een headless cms gaan met JS frontend framework zoals React, Angular of Vue.
WordPress is ook gewoon headless te gebruiken, plus je vergelijkt nu een kant en klaar basis CMS (wat WordPress helemaal niet hoeft te zijn) met systemen die aan de voorkant net zo veel performance nodig hebben. Een React frontend is niet per definitie sneller dan een WordPress applicatie.
En dat baseer je op? Gewoon grote onzin, WordPress is voor veel meer geschikt dan mensen denken. Je moet gewoon - net als met elk systeem - de moeite nemen zelf kwalitief goed spul te schrijven.
Waarom niet? Kun je je stelling onderbouwen?
Ik ben het met je eens. Wordpress is een uit de klauwen gelopen blogging platform wat nu te pas en on te pas overal voor wordt gebruikt. Zelfs gemeente Den Haag wil alle gemeentelijke websites (incl. GGD) over zetten naar Wordpress, dat is echt om te huilen. Ik geloof best (en heb zelf ervaren) dat Wordpress prima kan werken voor kleinschalige websites. Maar als jij op enterprise-niveau wil functioneren, zorg dan ook voor enterprise software.
Aangezien dit overheids sites zijn, vraag ik me af of hier ook bijv. Digid op gebruikt word. In dat geval zou je je ernstig zorgen kunnen maken of persoonsgegevens wel veilig zijn - dan wel er aan de richtlijnen van digid word voldaan.
Ik denk niet dat DigiD een WordPress website is... :P
Dat kan technisch prima; er zijn SAML-plugins voor wordpress.

Of je dat wil gebruiken en of het verstandig is, is natuurlijk een tweede..
Zou het je nog verbazen? Kijk hoeveel ICT projecten van de overheid op hun plaat gaan, ver over budget en na korte tijd weer gigantische update's nodig hebben.

[Reactie gewijzigd door Dracyn op 9 juni 2021 08:27]

In het bedrijfsleven gaan net zo veel ICT projecten op hun plaat maar die hoeven dat niet te rapporteren. Daar worden het onder operationele kosten geschoven en zolang de cijfers onder aan de streep goed geneog zijn is er niemand die vragen gaat stellen.

Bron: >30 jaar werkervaring in de ICT.
Ik sluit me hier volledig bij aan. Heb projecten voorbij zien komen die 3 a 4 keer hun begrote tijd hebben overschreden, vanwege diverse redenen zoals ondermeer scope creep en onvoldoende duidelijke en afgebakende klantwensen. Ook wordt er nog wel eens te laag ingezet met bieden op een opdracht om deze binnen te halen wat gewoon ingecalculeerd lijkt door de klant.
Volledig mee eens. Het ergste dat ik heb meegemaakt was een fusie (lees: vijandige overname) waarbij het performante systeem van het ene bedrijf werd uitgefaseerd ten voordele van een op Excel-tabellen gebaseerd systeem van het andere bedrijf.
Tsja dat is dikwijls te wijten aan ... Er wilt iemand zijn projectje doen zoals hij het wilt. Dikwijls genoeg gewerkt hier voor de overheid. Tevens de constante wijzigingen die er gedaan worden aan de wetgeving leveren ook dikwijls vertraging op. En bij die contracten is het 1 firma of meerdere die personeel leveren. Meestal wordt er niet naar de kwaliteit van het personeel gekeken, en is dat een "spring" plank voor vele juniors, want die bedrijven nemen elk jaar schoolverlaters aan en dan worden ze daar een jaartje gezet, zodat ze ervaring hebben om dan nadien ergens anders gezet te kunnen worden. En dan is er dikwijls nog de interne werking en huidige bestaande dingen waar je misschien moet mee interfacen. Dit is in 99% ook een zeer zware onderschatting, want niet alles heeft een API om even wat op te halen of weg te zetten. Dit is dikwijls op zeer omslachte manieren, of bestaat gewoonweg niet. De laagste bieder krijgt het project en dikwijls is het project ook maar zeer summier beschreven. Ik ken 10tallen Belgische projecten die gewoon een pak vertraging (lees dikwijls jaren) opgelopen hebben door bovenstaande factoren of gewoon gestopt zijn.
Aan de andere kant, zijn er wel projecten die wel werken, binnen budget zijn. Het kan wel, maar veel hangt af van de overheidsdienst zelf.
Om een DigiD-aansluiting te krijgen zijn er behoorlijk strenge audits. Zelf ken ik in ieder geval geen voorbeelden van WordPress-sites die DigiD gebruiken.

Edit: een gevolg van de strenge (en kostbare) audits is overigens dat vooral leveranciers van applicaties een aansluiting hebben. Denk aan Centric en PinkRoccade (hier een volledige lijst). Op die manier is er maar 1 audit nodig en worden de kosten doorberekend aan meerdere afnemers in plaats van 1.

Vraag me daarnaast af in hoeverre dat een probleem zou zijn. Die data komt immers niet in de WordPress-omgeving zelf te staan. Wellicht een MITM-aanval waarbij een kwaadwillende via een gehackte WordPress-installatie de linkjes naar DigiD-inlogpagina aanpast en via een neppe DigiD-pagina zo achter credentials kan komen?

[Reactie gewijzigd door sOid op 9 juni 2021 08:28]

Tot een van de plugins die je 'wel handig' leek een update pusht die even al het verkeer doorstuurt...

Nee, dan heb je alsnog geen wachtwoorden maar tokens etc, maar wel een enorm ongewenste situatie.
Naja voor coronatest.nl voldeden ze ook niet, maar kregen ze wel digid....
Trouw heeft dus simpelweg naar /wp-admin en varianten gezocht van de sites welke Wordpress gebruiken. Er staat niets over andere sites welke een ander CMS gebruiken en daarmee een andere (default) openbare admin login pagina. Onderzoek zegt dus heel weinig over de totale omvang. Dit zou zomaar een verveelde stagiair geweest kunnen zijn, en dat noemt Trouw dan ‘eigen onderzoek’.
Je gedachtengang kan best kloppen, maar je hele toon van neerzetten is een beetje "pwah, waar hebben we het over". Laat dat nou 1 van de dingen zijn die dus mis gaat bij dit soort projecten/sites: het bagatelliseren van het geheel (bijv. van de gevolgen).

Beveiliging hoort altijd en overal goed te gebeuren, ongeacht van de grootte of belang van een site of project. En voor mijn part gebruikt een overheid voor een project o.i.d. een Wordpress site, als je het maar voorziet van goede beveiliging en vooral ook: bijhoudt. En of het dan een stagiair is die tegen een paar lekke sites aanloopt, een FoxIT die een groot onderzoek doet, of wat dan ook: zorg dat je beveiliging op orde hebt.
Kwestie van zo min mogelijk plugins gebruiken en alles goed up-to-date houden. Dat is je echte beveiliging. Security through obscurity door het "verstoppen" van je admin pagina op een andere URL is nou niet echt hoogstaand. Onbereikbaar maken van deze pagina op basis van IP is dan wel weer goed, maar in principe niet nodig als de rest van je CMS gewoon up-to-date is.
Het admin deel uit de publiek site halen en dit enkel via VPN laten benaderen zou al heel veel schelen.
Dan snap je mijn reactie niet. Ik bagatelliseer het security risico juist niet. Ik zeg dat het waarschijnlijk nog veel groter is, maar dat het onderzoek naar de hoeveelheid websites nietszeggend is. Ja, zeker.. hier moet iets aan gedaan worden. Maar daarna stopt het weer.. laat nu een fatsoenlijk onderzoek uitvoeren wat verder gaat dan enkel een paar simpele checks op Wordpress sites.
Dit zou zomaar een verveelde stagiair geweest kunnen zijn, en dat noemt Trouw dan ‘eigen onderzoek’.
Wooow, dat jij die conclusies kan trekken op basis van de inhoud van het artikel. _/-\o_
Ik denk dat het niet alleen de websites van de overheid zijn die niet voldoende beveiligd zijn.
Overal zie je de gevolgen van twee belangrijke oorzaken:
1- de neiging om op alles te bezuinigen
2- de onwetendheid van beslissers op het gebied van ICT. Hoe kan je over iets beslissen wat je niet begrijpt?
Beslissingen over zaken die mensen inhoudelijk niet begrijpen komt vaak voor. Net alleen binnen de wereld van ICT. Eenvoudig voorbeeld zijn de ministers in Den Haag.

De meningen zijn verdeeld of vakkennis een vereiste is om (financiële) beslissingen te kunnen maken. Als je goed geadviseerd wordt hoeft het denk ik geen probleem te zijn dat je inhoudelijke kennis ontbeert.

Persoonlijk denk ik dat het probleem eerder te maken heeft met onderling vertrouwen. Je kan namelijk onmogelijk alles weten. Det een directeur van bijvoorbeeld een betonfabriek weinig van ICT afweet is mijns inziens zeer begrijpelijk en hoeft geen probleem te zijn. Zaak is wel dat hij iemand heeft die hem kan adviseren en waarop hij kan vertrouwen.

Ps. Ik weet van dichtbij dat dat vertrouwen zeer belangrijk is. Familielid heeft leidinggevende functie, maar moet voor veel van zijn beslissingen terugvallen op de deskundigheid van anderen. Wat ik met betrekking tot ICT gerelateerde onderwerpen helaas heb gemerkt, is dat als er de naam van een groot bedrijf en veel geld mee is gemoeid, al vrij snel wordt gedacht dat het wel goed zit…

[Reactie gewijzigd door JKP op 9 juni 2021 11:11]

Dit is wel (weer) een erg suggestieve titel. Als een beheersysteem voldoende beveiligd is met 2FA is er helemaal niets aan de hand als deze pagina publiek beschikbaar is. De code van de site komt uit dezelfde ontwikkelaarshanden / codebase. Dus als er ernstige lekken in zitten, zitten die ook in de website zelf (SQL injection).

Natuurlijk is het handig om een beheersysteem niet publiek beschikbaar te maken, maar je voorkomt er vooral problemen met een slecht inlogsysteem mee. Het is een beetje een pleister gebruiken voor iemand wiens arm helemaal open ligt.

Oftewel: weer lekker makkelijk scoren Trouw. Ga eens grondig onderzoek doen en kijk of je ergens in komt. In plaats van checken of alles wel 100% aan de regeltjes voldoet.
We hebben de kop inmiddels aangepast, want ook wij vonden het na wat discussie te suggestief.
maar omdat de pagina's openbaar vindbaar zijn, kunnen kwaadwillende hackers toegang proberen te krijgen tot de beheerderspagina's
Dat is op zich waar natuurlijk, maar jeetje, dat is wel een open deur. Tuurlijk kan je uitsluitend beheer-verkeer van bekende locaties toestaan, maar als je afhankelijk bent van obscurity dan zit er sowieso al iets niet helemaal goed.
maar als je afhankelijk bent van obscurity dan zit er sowieso al iets niet helemaal goed.
Maar wie zegt dat ze afhankelijk zijn van obscurity? Misschien zit er wel 2fa op
Alleen verkeer van bekende locaties toestaan is geen obscurity!
Vorig jaar wisten cybercriminelen toegang te krijgen tot een site van de gemeente Hof van Twente, waar iemand via een dergelijke inlogpagina binnenkwam omdat de gebruikersnaam 'testadmin' was en het wachtwoord 'Welkom2020'.
Is deze tekst weer blank overgenomen van Trouw, een DPG broertje/zusje.

Schaamtevolle kopie en vervolgens ook nog een tekst die niet klopt.
Het gehele onderwerp gaat over websites, "point of entry" bij de hack was niet een website.....
Volgens mij helpt het als er een keer minder copy/paste wordt gedaan en een keer met een journalistieke blik wordt gekeken voordat er publicatie is.


Om te kunnen reageren moet je ingelogd zijn


Apple iPad Pro (2021) 11" Wi-Fi, 8GB ram Microsoft Xbox Series X LG CX Google Pixel 5a 5G Sony XH90 / XH92 Samsung Galaxy S21 5G Sony PlayStation 5 Nintendo Switch Lite

Tweakers vormt samen met Hardware Info, AutoTrack, Gaspedaal.nl, Nationale Vacaturebank, Intermediair en Independer DPG Online Services B.V.
Alle rechten voorbehouden © 1998 - 2021 Hosting door True