Cookies op Tweakers

Tweakers maakt gebruik van cookies, onder andere om de website te analyseren, het gebruiksgemak te vergroten en advertenties te tonen. Door gebruik te maken van deze website, of door op 'Ga verder' 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

Door , , 84 reacties
Submitter: nickurt

Wordpress heeft een ernstig beveiligingsprobleem opgelost, nadat dit door onderzoekers aan Automattic was gemeld. Door het lek was het mogelijk om via de functie voor automatische updates malware naar Wordpress-sites te sturen, die 27 procent van het internet vormen.

WordPress fpaBeveiligingsbedrijf Wordfence schrijft dat elke Wordpress-site ieder uur een verzoek naar de updateserver stuurt om te controleren of er een nieuwe versie van het cms en gerelateerde software beschikbaar is. De server stuurt vervolgens een antwoord met een url als er inderdaad nieuwe versies zijn. Doordat een aanvaller de updateserver binnendringt, is het mogelijk om deze url aan te passen naar kwaadaardige software, schrijft het beveiligingsbedrijf. Het aantal getroffen sites zou daarbij groot zijn, omdat de automatische updatefunctie standaard is ingeschakeld.

Het lek heeft te maken met een webhook, waarmee Wordpress-ontwikkelaars op GitHub broncode kunnen opslaan. Op het moment dat zij code op GitHub toevoegen, wordt er via deze functie contact opgenomen met de updateserver die vervolgens notificaties uitstuurt. De php-code van deze functie bevatte volgens het beveiligingsbedrijf een kwetsbaarheid, waarmee een aanvaller willekeurige code op de updateserver kon uitvoeren. Doordat de webhook toestaat dat de aanvaller zelf een hashingalgoritme kiest voor authenticatie, was het mogelijk een zwak algoritme te kiezen en er vervolgens een brute force-aanval op uit te voeren.

Op die manier was het binnen enkele uren mogelijk om met behulp van het adler32-algoritme achter het shared secret te komen en op die manier toegang te krijgen tot de updateserver. Automattic heeft het lek in september al gedicht en heeft het beveiligingsbedrijf voorzien van een beloning. De onderzoekers blijven kritisch over de rol van de Wordpress-updateserver, omdat deze een single point of failure vormt. Andere partijen hebben eveneens kritiek aan het systeem geuit, zo maakte een onderzoekers onlangs zijn ongenoegen bekend via een mailinglijst.

Moderatie-faq Wijzig weergave

Reacties (84)

Nog zonder de link te openen wist ik wie die beveiligingsonderzoeker was (Scott Arciszewski), hij heeft al meerdere malen publiekelijk gewaarschuwd voor de gevaren van het Wordpress automatische update systeem. Er is wel zo vreselijk mee mis dat het gewoon een keer fout moest gaan!
https://paragonie.com/blo...lements-automatic-updates

De kern van het probleem, bij updates van het OS worden alle downloads digitaal ondertekend (niet het geval bij Wordpress), alleen de checksum van de bestanden word gecontroleerd (is te vervalsen, helemaal omdat ze MD5 gebruiken). En dan is een gehackte server genoeg om de hele wereld in vuur en vlam te zetten. Als je het CDN van Microsoft hacked en valse updates uitbrengt moeten die dan nog wel ondertekend zijn met een geldig certificaat (vandaag de overstap naar sterkere standaards).

Dit is niet op zichzelf staand, een tijdje geleden was de populaire W3Cache plug-in lek, en wat ik daar allemaal aantrof was niet normaal. Toegegeven bij nieuwe versie was aardig verbeterd.
Maar waarom worden dit soort simpele problemen niet periodiek onderzocht?
http://www.webhostingtalk...bben-fix.html#post1315146

Ik wil mezelf niet teveel op de borst kloppen (ik maak immers ook fouten), maar als ik iets nieuws leer over beveiliging loop ik vrijwel meteen al mijn actieve projecten na om er zeker van te zijn dat ik niet kwetsbaar ben, en dat doe ik heus niet voor de lol... maar het levert vaak wel de nodige verbeteringen op. Bij dit soort grote projecten zou dit bijna een verplichting zijn, helemaal omdat W3Cache ook een pro versie heeft. Geen tijd? prioriteit!.

Kijk naar de vorige versie van de Webhook, " // Assuming Magic Quotes disabled like a good host." Assuming? 8)7 bij dit onderdeel, buiten het feit dat dit de slecht idee is assumptie niet bepaald wat ik als programmeur zou willen zien.

https://core.trac.wordpress.org/ticket/25052 (discussie van 3 jaar terug)

* "This signing may not be needed however, as it would effectively duplicating the HTTPS efforts". Want waarom zouden we ook extra gebruiken :') ik heb immers geen remmen nodig, want ik heb al een airbag?

Er is een hele cultuur bij Wordpress dat veiligheid totaal niet serieus word genomen, ze gewoon doen wat zij "denken" dat goed is en bijna alle advies van echte beveiligingsexperts negeren of in twijfel trekken.

Scrott's laatste comment slaat de spijker op z'n kop: " I'm no longer contributing to WordPress core due to disagreements that aren't really up for discussion here."

Composer is zelf ook geen silver-bullet overigens, en ook bekend dat dit een probleem is.
Alleen is hier de distributie heel anders geregeld, en veel moeilijker op te lossen. Wordpress core word centraal geregeld en dus is er vrijwel geen excuus om dit normaal op te lossen.

Om precies te zijn heeft CMS Airship zijn update systeem helemaal dichtgetimmerd https://cspr.ng/, maar als Wordpress dit zou doen krijg je waarschijnlijk allemaal klachten dat hun "hoster" het niet ondersteund. En zo is de wereld weer rond.
PHP heeft hier allang een oplossing voor in Phar en PharData.
Ik heb dit net in gebruik genomen voor een nieuwe versie van mijn CMS omdat PHP 5.4 eindelijk EOL is.
Via Phar/PharData krijg je gewoon vrolijk een error als de OpenSSL Signature niet goed is.
Voorbeeld, Download:
- https://dragonflycms.org/downloads/v10/modules/example.tgz
- https://dragonflycms.org/...PM-DragonflyCMS-10.pubkey (hernoem deze naar example.tgz.pubkey)
Open de example.tgz eens met PharData() zonder de pubkey en eens met.

GPG is hier dus niet aan de orde, maar wel een OpenSSL Key, en met reden!
PHP heeft wel een pecl-gnupg extensie, maar die staat eigenlijk nooit op een server, waardoor het idee van Scott Arciszewski best zinloos is in de PHP wereld.
WordPress heeft daarnaast het probleem dat ze oude PHP versies willen blijven ondersteunen, en dat is het grootste probleem 8)7
Dit probleem blijf je toch altijd houden?

Software houd je veilig door het te voorzien van updates. Gebruikers zijn te lui/hebben te weinig kennis, dus standaard doe je auto-update (zie ook windows).

Gevolg: beveiliging update-server wordt van cruciaal belang. Altijd een spof dus.
Je haalt nu twee dingen door elkaar:

1. De update-server is een SPOF.
2. De update-server moet superveilig zijn.

Punt 1 heeft iedereen last van, en dat kan je opvangen met goede CDNs en andere zaken. Punt 2 kan je ook opvangen met certificaten, hardened servers en meer van die dingen.

Wordpress heeft misschien aan een oplossing voor punt 1 gedacht (hur hur we huren wel ruimte bij Akamai) en sowieso NIET aan een oplossing voor punt 2. MD5 hashes vanaf dezelfde server :'(

Dus ja het is een SPOF voor zowel Microsoft, Apple en Ubuntu (om maar drie grote auto-updatende partijen te noemen) maar er is wel ff een verschil tussen Wordpress en de rest.
WordPress heeft al langer een probleem met wachtwoorden vanwege dat ze (vooralsnog) te veel backwards compatible willen blijven om zo ook op niet goed onderhouden (lees: niet geüpdatet servers qua PHP versie) te kunnen blijven draaien.

Aan de ene kant logisch dat je een mate van backwards compatibiliteit aanbied maar het nog altijd ondersteunen van PHP 5.2 met EOL 6 jan 2011 schiet wellicht wat te ver door...

Een kortere periode van backwards compatibiliteit zou wellicht ook de omvang en de snelheid van de WordPress core ten goede kunnen komen...

Terug on topic - het zou me *stiekem* niets verbazen als ze gewoon de wp_hasher code gebruiken op hun update server.

Hier wat interessante linkjes mbt het wachtwoord systeem van WordPress:

[Reactie gewijzigd door gooos op 24 november 2016 09:05]

Ik heb geen incidenten gezien waarbij wachtwoord bij wordpress misbruikt werd.

En we hebben er 10.000 sites van draaien.

Probleem is dat wordpress laagdrempelig is en standaard elke plugin/module toelaat.

Gebruikers zijn functioneel gericht dus die installeren van alles en nog wat zonder zich te realiseren dat alles wat je kunt toevoegen ook problemen kan introduceren.

We hebben ook eens meegemaakt dat klanten te gierig waren om een template te kopen en die van een Russische site "gratis" gingen downloaden, waarin netjes door Russen al backdoor was ingebouwd.

Maar Wordpress is gewoon dicht te timmeren als je maar weet wat je doet en dan zal autoupdate juist onwenselijk zijn.
Dat heb ik gelukkig ook niet meegemaakt tot op heden, maar het ging mij om het feit dat Automattic vooralsnog de neiging lijkt te hebben om met betrekking tot hashes en dergelijke aan oude technieken vast te houden vanwege de backwards compatibiliteit. Het verhaal rondom de wachtwoorden is daar een prima voorbeeld van. En het gebruik van zo'n functie ergens anders in het eco-systeem zou me dan ook niets verbazen.

Maar wat betreft laagdrempeligheid... eens, dat is zowel de kracht als ook de zwakte van WordPress. Eerlijk gezegd zouden ze vanwege hun omvang op het web best wel een beetje het voortouw mogen nemen om webhosters te dwingen om hun PHP versies bij te werken door wat oudere versies via een roadmap uit te faseren. Een ruim 5 jaar oude PHP 5.x versie moet gewoon niet meer kunnen.
Vergeet niet om bij hashes terecht te komen heb je al toegang.

Indien je via één account bij de hashes van andere accounts kunt komen heb je een ander probleem.

Verder wil webhoster wel laatste versie van PHP draaien echter zullen ze klanten kwijt raken.

Veel eind gebruikers draaien oude versies of gebruiken plugins/modules waar geen nieuwe versie van is en daarmee incompatible met nieuwe PHP.

Sites die ooit eens door een webdesign bedrijf zijn gemaakt, worden niet geupdate omdat webdesigner daar geld voor wil zien.

Het is een kip en ei situatie.
Update server van Microsoft is eens gehacked door een Nederlander (Dimitri) .

Hoe wil je CDN's gebruiken om punt 1 op te vangen. Als bron van nieuwe code aangevallen kan worden zul je dus ook aangepaste code repliceren naar je CDN's.

En dan maakt de rest niet meer uit.

Update mechanisme is en blijft een interessante aanvalsvector ongeacht leverancier/toepassing. (zie artikel van Chinese telefoon fabrikant vorige week)

Even los van ongewenste derden mutatie aan updates, wat dacht je van gebrekkig geteste code die uitgerold kunnen worden.
spof op gebied van beveiliging bedoel ik. Als een update-server gehackt is, wordt elke gebruiker ter wereld gehackt, komt het ongeveer op neer. Hoeveel beveiligingsmaatregelen je verder ook neemt op je 'client'... Het update-mechanisme mag toch alles en gaat bijna blind uit van veilige gegevens op de update-server.
Automatische updates gaan niet werken omdat alles afhankelijk is van elkaar.
Je hebt:
-Wordpress core
-Plugins
-Thema's
-...

Dan heb je een update van wordpress, echter kan die update je plugin of thema slopen waardoor je site op zn gat ligt. Als die plugin redelijk diep geimplementeerd is dan kan je die ook niet vervangen met een ander alternatief. Of als de thema die je gekocht hebt die niet meer onderhouden wordt dan kan je ook niet zomaar wisselen.

Wordpress is leuk om goedkoop een gelikte site te hebben, maar indien je serieuzere plannen hebt dan is het verstandiger om een maatwerk website te hebben.
Ik zou me eerder afvragen wat voor half bakken vage theme/plugin ik gebruik en wat die doet als hij over de zuiger gaat van een security update.
Vooropgesteld, ik ontwikkel niet voor Wordpress sites, maar ik neem aan dat er gewoon standaarden/api's gedefinieerd zijn om mee te werken zodat je website niet van een random update over zijn zuiger gaat?
Laat ik nou net een bug moeten fixen bij iemand die een update had geinstalleerd.
Een bekende contactformulierplugin met meerdere miljoenen installaties die was kapot gegaan. Je kon geen spaties gebruiken in formulieren. Kwam door een of andere fotogalerij op die pagina die vond dat de spatietoets bedoeld was om naar de volgende foto te navigeren.

Hoe goed er ook ontwikkeld is, je blijft dit soort problemen houden als je site zo bloated is met allemaal modulaire plugins. DIe site waar ik mee beziig ben zitten 3 plugins op en een thema die in de lijst stond als meest populaire thema's

[Reactie gewijzigd door com2,1ghz op 24 november 2016 15:51]

Wordpress: een backdoor met blogfunctionaliteit.
Ik had een wordpress blog met alleen maar extensies van Automatic, deze update automatisch. Maar blijkbaar zat ik op een lijst van 'blogs waarvan we weten dat ze WP draaien', want om de paar maanden werd mijn blog weer geinfecteerd. Gelukkig had ik een zeer oplettende host waardoor ik er meestal snel wat aan kon doen. Maar ook zei konden me niet helpen met die onzin veiliger maken/afstellen.

Uiteindelijk alles maar omgezet naar Jekyll, dan heb je alleen maar statische html online staan. Mijn blog laad nu honderd keer sneller en je kunt 'm alleen hacken met exploits in Apache of door het FTP wachtwoord te weten. Heb er nu geen omkijken meer aan :).
Ik hoop dat je met "FTP wachtwoord" eigenlijk "SFTP wachtwoord" bedoelt want FTP stuurt je wachtwoord in leesbare tekst het internet over en iedereen die het verkeer kan onderscheppen weet dus jouw wachtwoord. En er zitten nogal wat schakels tussen jouw systeem en de hoster. Als je inderdaad nog het stokoude FTP gebruikt vind ik het niet zo raar dat je iedere maand gehackt wordt.
Traffic sniffen is niet zo eenvoudig als iedereen maar denkt. 'Er zitten nogal wat schakels tussen' valt vaak ook wel mee. Veel meer dan ergens tussen de 5 en 8 hops zijn het niet.

Al die hops zijn routers waar je niet zo even een traffic sniffer op start met als doel FTP wachtwoorden te sniffen.

Theoretisch kan het, maar in praktijk loopt het niet zo'n vaart. Het is een ander verhaal wanneer je gaat FTP'en over publieke (onbeveiligde) WiFi verbindingen. Maar vanaf je ADSL of kabelaansluiting FTP'en naar een Nederlandse hoster zou ik niet zoveel problemen hebben. De kans dat dat wordt gesniffed met als doel het onderscheppen van FTP gegevens is nihil.
Jij hebt wel erg veel vertouwen in je ISP, Netwerk supllier en Hoster.
(ergo een ieder die dit zonder probleemen kan doen zonder dat jij het ooit kan merken)

Verder vertouw je ook je geheele lokaale netwerk (meestal is het geen probleem om van af een andere systeem het gehele lokaale subnet te sniffen)

Ook vertrouw jij er maar op dat je lokaal geen sniffer hebt, Onbeveiligde communicatie is vaak door veel meer programma's te zien dan beveiligde verbindingen (er is namelijk geen rrede om het geheim te houden)
Dit, plus dat de NSA, AIVD, GCHQ en vele anderen de laatste tijd wel hebben laten zien dat je overal een logger tussen kunt krijgen als je maar een beetje duwt. Ik weet zeker dat minstens 5 partijen dat FTP wachtwoord ergens in een database hebben staan. Of ze er iets mee doen is een tweede, maar veilig is het zeker niet. FTP gebruiken in 2016 kan echt niet meer.
Of FTP-S (FTP over TSL)
Ik geloof niet dat mijn host SFTP of FTP-s aanbied, volgens mij is dat nog steeds niet echt een courante techniek voor simpele blogs. Voor de grap heb ik even met tracert nagekeken waar mijn wachtwoord in plain text langs komt.

1. Mijn PC
2. Mijn Router (van KPN)
3. KPN
4. Eurorings (KPN internationaal)
5. Mijn webhost

Hierbij is mijn PC zeer waarschijnlijk de zwakste schakel, en mijn webhost kan al bij de data. In theorie ben ik dus niet helemaal veilig.

In de praktijk is dit ongeveer even veilig als je huissleutel. Je hebt er 5 laten maken, maar de sleutelmaker had best stiekem een 6e kunnen maken, of misschien dat een heeft gemaakt terwijl de sleutelmaker niet keek.
Je kunt inderdaad met geautomatiseerde bots heel snel opvragen waar wordpress sites staan. Sommige werken met de standaard wordpress configuratie, anderen verraden zichzelf al met /wp-content/*.* of /themes/themenaam/ enz.

Het is niet zo lastig een exploit te zoeken hiervoor. Als je weet dat Thema /Tweakers.net/ lek is dan zoek je actief op alle wordpress sites die het thema van /Tweakers.net/ draaien. Voer je exploit grootschalig uit en voila, je malware wordt op honderden sites aangeboden.

Wordpress is mooi maar de community doet er iets verkeerds mee. Het maken van websites met plugins en thema's waar nauwelijks audit op valt. Hierdoor riskeer je dat de boel gewoon gehacked wordt met gevolgen vandien.
Sterker nog, slimme aanvallers indexeren alle sites die ze scannen in een database. Als er dan een vulnerability bekend wordt in een bepaald product hoef je niet meer op zoek te gaan met een internet brede scan naar wie dat product gebruiken, je hoeft alleen maar in je lijst op te zoeken wie dat gebruiken en kun je binnen een minuut na publicatie een aanval starten.

Dat heeft verder niets met WordPress te maken, dat geldt voor alle dingen die aan het internet hangen. Daarom is het ook belangrijk dat je diensten niet exact op hun internetface vermelden welke versie ze zijn. "Product X" is niet zo'n probleem, "Product X 6.3.2 build 3128" is dat wel.
Security through obscurity, puik plan! :>
Ja ik heb ook veel last gehad van infecties met Wordpress. Kreeg ik weer mailtjes van een of andere bank dat iemand een phishing pagina op mijn server had gezet. Toen dat de tweede keer gebeurde heb ik gewoon een HTML + CSS template gepakt en de hele site opnieuw gemaakt. Nu nergens meer last van.
Ftp? Nooit gebruiken. Is zeer onveilig vanwege clear text wachtwoorden.
Je hoeft daarvoor niet op een lijst staan. In de access logs van mijn servers zie ik ontiegelijk veel requests aan allerlei sites die geen WordPress draaien en ook nooit gedaan hebben. De requests zijn wel naar bekende WP exploits, of exploits in plugins. Ook naar Joomla-exploits, daarvoor geldt hetzelfde eigenlijk. Aanvallers proberen gewoon dergelijke exploits toe te passen op élke site die ze tegenkomen, los van of daar WordPress op draait of niet.
Idd. Het is ooit als een blogsysteem begonnen en is toen uit de klauwen gegroeid tot een "cms". Dit brengt gewoon erg veel problemen met zich mee, en dat het halve internet Wordpress gebruikt maakt het alleen maar erger.
moet je mij is het verschil tussen een cms en blogsysteem duidelijk maken, want volgensmij doet een CMS niets anders dan wat een blogsysteem doet.... :+
En CMS is een Content Management System. Een blog onderdeel is maar een minuscuul iets van een CMS.

Wil je in Wordpress bv een pagina waarop je je projecten toont. Dan moet je een functionaliteit die bedoeld is voor bloggen gaan ombuigen om het voor een project werkbaar te krijgen. Allemaal mogelijk, maar in de code erg omslachtig.

Heb een paar Wordpress sites onder mijn beheer gehad, een keer maar nooit weer. Het eerste waar je mee bezig moet gaan na i stallatie van Wordpress is de beveiliging. 101 plugins installeren om de boel veilig te houden.

Misschien is Wordpress in de basis wel goed, dat weet ik niet. Maar voor mij is het alleen maar tegen gevallen. En omdat het zo Mega populair is ben je gewoon doelwit voor hackers.

Er zijn voldoende alternatieven, maar vaak niet zo plug en play als Wordpress. En daar kan iedere huisvrouw / man niet mee overweg.
Dat laatste is het hele probleem. Ik zocht naar alternatieven waar je ook gewoon een betaald thema voor installeert en dat de site 'front end' kan opbouwen en onderhouden. Dan is Wordpress je enige keuze. Voor simpele maar toch mooie, strakke sites voor bijv een yogadocente (die simpelweg niet het budget heeft) is Wordpress echt perfect, icm met een goed thema en een goedkope host.

Maar tegenwoordig heeft Wordpress auto-update, dus in elk geval komen security patches vanzelf door.
Maar tegenwoordig heeft Wordpress auto-update, dus in elk geval komen security patches vanzelf door.
Maar, zoals in dit artikel te lezen is, kan daardoor soms malware ook vanzelf doorkomen.

Ik denk dat in principe het auto-update systeem in WordPress wel meer problemen oplost dan het introduceert, maar in principe zou een CMS-systeem gewoon geen schrijfrechten naar zijn eigen bestanden moeten hebben. Het is de ene na de andere exploit, dan wel in WordPress Core, dan wel in plugins, die de boel kapot maken. Als de PHP-code gewoon read-only was konden dergelijke exploits helemaal niet voorkomen.

Goed, dan is het minder gebruikersvriendelijk. Veiligheid en gebruikersvriendelijkheid voor de beheerders gaan eigenlijk per definitie gewoon niet goed samen.
Ben het helemaal met je eens.
Toen ik op zoek ging naar alternatieven, was ik stomverbaasd dat er eigenlijk wel een hoop andere mogelijkheden zijn maar anno 2016 geen enkele echt zoveel gemak geeft en goedkoop is. Jammer. Aan de andere kant zijn het vaak helemaal geen belangrijke sites, dus mss ook niet interessant om aan te vallen, ook omdat ze wellicht niet veel bezoekers hebben.

Ik neem aan dat wat grotere, belangrijkere sites geen Wordpress gebruiken.

[Reactie gewijzigd door Jazco2nd op 24 november 2016 11:43]

Gelukkig wordt WordPress inderdaad vooral gebruikt door individuele bloggers en kleine organisaties. Alsnog zitten daar best wel populaire sites tussen, dus de impact is veel groter dan hij zou moeten zijn.

En helaas zijn er zelfs eCommerce addons voor WordPress waarmee je je WordPress blog kunt uitbreiden met webshop-functionaliteit. Een dergelijk onveilig systeem toegang geven tot klant- en betaalgegevens is wel angstaanjagend. Een site die WordPress als eCommerce-oplossing gebruikt zal ik zelf dan ook nooit wat bij bestellen.
Beetje kort door de bocht hoor.

Er zijn toch heel wat kleine organisaties met een omzet van ¤100 miljoen die Wordpress gebruiken als corporate website.

Ook zijn er zat WooCommerce webshops die miljoenen per maand omzetten en dat heel veilig doen. Ik ben althans nog geen grote koppen hier op Tweakers tegengekomen dat er grote WooCommerce sites gehackt zijn.

Maar daar kom jij nooit begrijp ik ;)
Nope, daar kom ik nooit. Los van of WooCommerce grote lekken bevat, je hoeft maar een kleine plugin met een enorm lek te installeren en je website is kwetsbaar. Gezien het enorme aantal WordPress hacks is dat geen onrealistisch scenario. Dat het nog niet op grote schaal voorgekomen is betekent niet dat het daarmee veilig is.

Natuurlijk, een goede, actieve webmaster die de boel goed in de gaten houdt, braaf alle security updates installeert, de PHP code geen schrijfrechten op zichzelf geeft en geen add-ons gebruikt tenzij hij ze zelf uitvoerig beoordeeld heeft kan een hoop verschil maken. In de praktijk zie je dat er overal te weinig budget voor ICT en zeker security beschikbaar is. Er zijn zat prima ecommerce-oplossingen beschikbaar waarvan de code op een veel hoger niveau staat dan dat rommelzootje van WordPress wat maar comaptibel wil blijven met antieke PHP-versies. Heb je de code ooit wel eens bekeken? Ik was ooit van plan om een add-on te maken maar ben huilend weggelopen toen ik die hoop rommel zag. :X

[Reactie gewijzigd door MadEgg op 24 november 2016 12:17]

Toen ik op zoek ging naar alternatieven, was ik stomverbaasd dat er eigenlijk wel een hoop andere mogelijkheden zijn maar anno 2016 geen enkele echt zoveel gemak geeft en goedkoop is.
Dat is misschien wel zo. Maar als bedrijf moet je misschien niet willen dat Jannie van Marketing ff een website in elkaar sleept. Je administratie laat je ook door professionals doen.

Anno 2016 is een website niet meer zoals het in 2000 was. Je moet aan veel meer zaken denken en rekening mee houden. Ook beveiligings zaken waar Jannie van Marketing geen enkele weet van heeft.
Front-line editting heeft Drupal ook al jaren, dus weet niet hoe je er bijkomt dat alleen Wordpress dit kan?
Dat zeg ik toch niet? Je pakt echt 1 dingetje eruit en doet nu net alsof ik daar een punt van heb gemaakt.

Als ik haast 0 euro wil besteden, gewoon een simpele filehost en een mooie website erop wil en die ook nog eens met haast 0 kennis wil onderhouden (front end editing), kom je uit bij Wordpress + goed thema (waar je eenmalig wel wat aan kwijt bent).

Dat andere veel betere systemen ook front end hebben is totaal niet boeiend omdat ze niet geschikt zijn voor de doelgroep die ik bedoel.

[Reactie gewijzigd door Jazco2nd op 24 november 2016 13:35]

Wij gebruiken voor klanten vaak Concrete. Genoeg click en done, goede uitbreidbaarheid,goede beveiliging en versie-beheer van de pagina's.

con : je hebt een deftige server nodig. De performance is maar zo-zo.

[Reactie gewijzigd door hackerhater op 24 november 2016 10:14]

Ik ben zelf erg gecharmeerd van Bolt cms. De installatie is min of meer plug and play. Daarna moet je wel iets meer moeite doen om een site helemaal werkend te krijgen. Maar het draait erg soepel en kan standaard ook op een SQLite database. Voor een onepager of een kleine site werkt dit soepel genoeg.

Er zijn overigens wel thema's en plugins voor Bolt, maar niet zoveel als voor Wordpress.

Bolt is overigens ook nog eens van Nederlandse bodem!
Dit is exact waarom ik na Joomla! en Wordpress waar alles zo vast gedefinieerd is qua inhoudstype (een titel en een tekst-veld, dat is het standaard, zonder dat je third party modules nodig hebt) over ben gegaan naar Drupal, waar dingen veel meer lego-stenen zijn in plaats van volledige systemen, zoals de plugins van Joomla! en Wordpress vaak zijn. Dit integreert veel dynamischer met elkaar en geeft ruimte voor aanpassingen, zonder dat je voor elke wijziging weer een module nodig hebt. Nadeel is dat de instapdrempel wel wat hoger is.
De hele werkwijze is onlogisch als je niet een blog wil maken. Alles is er op ingericht. De enige reden waarom het zo'n fijn systeem is, is omdat er zoveel plugins beschikbaar zijn.
Ik ben allang blij dat hij automagisch update. Zometeen heb je een hele kudde servers die niet geüpdated worden omdat niemand er naar omkijkt, dan heb je een veel groter issue in mijn ogen.

En hoe ik mijn vrouw moet gaan leren WordPress te updaten zonder auto-update heb ik écht geen idee van.
Ja doei. Ik snap je punt, maar het is die houding dus precies die het probleem is.

Er zijn al hele kuddes Wordpress sites die niet geupdate worden: alle servers die een oude versie draaien. Alle servers die de webserver geen schrijfrechten willen geven in de Wordpress-map (wat iedereen toch doet :F). En ga zo maar door. De magische "auto update" functie kwam er ook alleen omdat er elke update ook tientallen security issues werden gefixt.

De druk was al ongelofelijk hoog op Wordpress om hun backdoor weblog-software beter te beveiligen. En elke keer maken ze zich er met een jantje-van-leiden vanaf. Nu ook weer. Een MD5 hash vanaf dezelfde server :'(. Dat programmeert mijn neefje van 5 nog beter.

[Reactie gewijzigd door JCE op 24 november 2016 09:11]

Het is open source, dus voel je vrij om te helpen als je het beter kunt.
Het heeft niks met de source te maken. Het heeft met hun beleid te maken. Zolang ze PHP 5.2 willen blijven ondersteunen, zolang ze backwards compatible willen blijven, is er niks aan te doen. Open source of niet.
Ben blij dat mijn twee sites vorige maand over heb gezet van php7. Niet dat dat helpt op dit moment. Goed dat het nu is opgelost (en wachten we tot er weer iets nieuws is gevonden)
Waarom :F? Het is juist een goede security practise om de webserver geen schrijfrechten te geven op bestanden in het systeem. Zowel wordpress zelf als de plugins. Dan kan een aanvaller ook nooit code veranderen en daarmee de site infecteren met malware. Je bent in 1 klap van een hoop vormen van aanvallen af. Het is juist dom om alle schrijfrechten maar gewoon open te laten staan voor een proces dat vanaf het internet bereikbaar is. Vergeet niet dat een hoop lekken niet eens in WP zelf zitten maar in de addons met veel lagere security standaarden dan de WP-kern.

Enige uitzonderingen zijn sql-injecties (database moet altijd schrijfbaar zijn) en eventueel bestand-uploads als je die aan hebt staan, maar op de meeste wordpress sites hoeven toch geen bestanden te worden geupload?


[edit adhv reactie hieronder:]
Ja, het kwam inderdaad over alsof je bedoelde dat het stom was om geen schrijfrechten te geven omdat je daarmee de automatische update zou blokkeren ofzo. Blij om te horen dat dat niet zo is :)

[Reactie gewijzigd door kozue op 24 november 2016 09:19]

Het zou helpen als WP updaten via FTP-S/S-FTP zou ondersteunen zodat je niet de hele site schrijfrechten moet geven -_-'
Dat kon in het verleden wel, hebben ze dat eruit gesloopt?

In ieder geval helpt dat niet; in die implementatie onthield het systeem het wachtwoord ook namelijk. Daarmee heeft de code dus feitelijk autonoom toegang tot zijn eigen bestanden, en daarmee kunnen plugins dat dus ook.

Update via (S)FTP zou alleen helpen indien je gedwongen elke keer een wachtwoord moet opgeven, en zelfs dan moet je maar hopen dat er niet stiekem een plugin meeluistert. Updates zouden gewoon op initiatief van de beheerder geinstalleerd moeten worden. En aangezien de laksheid heeft laten zien dat dat te vaak niet gebeurt zou ik er 0 bezwaren tegen hebben als WordPress gewoon weigert te functioneren als er bijvoorbeeld langer dan 7 dagen geleden een security-update is uitgekomen en nog niet is geïnstalleerd.
Geen idee, ik moest een paar maanden geleden een WP-site op zetten en toen ik verschillende dingen niet (zoals thema's installeren) als ik de site schrijfrechten af nam.

Natuurlijk kan mallware specifiek geschreven om de wachtwoorden te jatten dan nog steeds iets, maar het maakt wel de drempel een heel stuk hoger.
Zeker omdat dat je dwingt de bestanden helemaal te overschrijven ipv dat je een string aan het einde kan plakken.
Het kan wel, maar het is een stuk meer werk dan een simpel :
$file = fopen('hoofdbestand','a');
fwrite($file,'mallware string');
fclose($file);

Mijn eigen systeem heeft alle belangrijke bestanden onder composer staan en de checker gooit ook een alarm als de core achter gaat lopen.
En wat ook helpt : PHP 5.6 als minimum. Eronder werkt het compleet niet.

[Reactie gewijzigd door hackerhater op 24 november 2016 12:15]

Je kunt toch gewoon elke keer de nieuwe versie van WordPress downloaden en overschrijven? 8)7 Heeft niks met 'ondersteunen' te maken.
Ja dat kan,
Echter als het ondersteund zou worden kan je de boel op auto-update kunnen laten zonder de hele site schrijfrechten te geven.......
Ehm, dat was mijn punt ook? Maar dat komt in combinatie met de :F smiley niet lekker over zie ik. Zal mijn post aanpassen.
En dan zal je net zien dat een laatste update van wordpress niet compatible blijkt te zijn met je plugin, thema of ander item waardoor je hele site slecht tot niet meer werkt.
Automatische updates zijn alles security patches die tot niks kapot mogen maken. De enige bekende uitzonderingen zijn plugins die dingen op een verkeerde manier deden.
tja, zijn toch gevallen bekend met een zeer populaire SEO plugin die heel wat sites de whitescreen of death (php fatal errors) gaf toen ze maar even een update erdoorheen moesten drukken ;)

Nadeel is dan ook dat als je niet zelf de zipjes download je ook de oude versie erg omslachtig binnen moet halen.
Correct. Het was niet die seo plugin alleen maar ook tientallen andere plugins, of thema's die na een update van wordpress gewoon NIET meer werkte.

Als wordpress een bepaalde functionaliteit eruit haalt of aanpast dat nodig is in een plugin of theme dan is het al voldoende om de boel te laten crashen.
Nu werkt de code van WP niet bepaald mee, maar dat hoeft niet aan het CSM te liggen.

Ik had ook eens dat een externe partij klaagde dat mijn updates zijn code kapot gemaakt had. Toen had ik iets van : euhm gast, die functies staan al een hele major op deprecated
Maar leest men die uberhaubt?

Je moet bij de update knop gewoon een melding doen van Major update, blabla deze en dat functie is vervangen etc.
Blijkbaar niet altijd, eigen schuld dan als dev.

Als een platform-leverancier functionaliteit als deprecated aan merkt is dat een harde waarschuwing van deze functies gaan verdwijnen. Gebruik ze niet.

Hetzelfde als je deprecated functies van de taal gebruikt.
Tjah dan gaat je code kapot bij de volgende major.

Elke fatsoendelijke IDE geeft meldingen als je functies gebruikt waar @deprecated in het functie-commentaar staat.

[Reactie gewijzigd door hackerhater op 24 november 2016 12:00]

[software/hardware] : een backdoor met [main_functie]funcionaliteit.
Microsoft
Iphone
Android
Playstation [1-4]
...

Het update beleid van de soft/hard-ware is veel belangrijker dan je op niks slaande opmerking, alle grote software pakketten bevatten tal van exploits/bugs/kwetsbaarheden en als je succesvol bent dan ben je een makkelijk target... Wat is het alternatief ? Allemaal naar Facebook gaan ? Of verwacht je echt dat alle bloggers leren "static rendering bloggen" ? Als ik WP vergelijk met bijvoorbeeld phpBB die nog manuele updates nodig heeft ... dan weet ik wel welk platform mijn voorkeur heeft.
Ik wist dat Wordpress populair was maar 27% van het internet? Dat is behoorlijk veel. Klopt dat wel?
Ja, hier dezelfde verbazing.... 27% is echt heeel erg veel, kan ik me bijna niet voorstellen.
60% van alle CMS-en is Wordpress.

Ongeveer 25 tot 30% van "alle" sites (CMS agnostisch) is ook Wordpress.

(disclaimer - artikel is afkomstig van een WordPress studio) - 2015
Right now, WordPress claims a 24% share. We decided to dig through the statistics to try and find out a bit more about where they come from, what they really mean and how WordPress may need to adapt to hit its target – and if such a seemingly ambitious target is reasonable.

Of course, one must bear in mind the scale of the web: 24% market share is huge. As I began writing this post, WordPress 4.2 (the latest version) had been downloaded 48,258,660 times. In just the time until I finished it, that figure had risen to 48,282,215 (23.5k downloads).
Wellicht tijd voor een goed onderbouwd CMS-vergelijkings-artikel op Tweakers :Y)

[Reactie gewijzigd door deathgrunt op 24 november 2016 09:28]

Ik kreeg ooit van een klant (kleine lokale ondernemer) die gehackt was door een lek in een specifieke plugin het verwijt dat ik Wordpress gebruikte en dat ik maar een nieuwe site moest maken, want haar "mannetje" had ingefluisterd dat Wordpress zelf niet te vertrouwen was.

Of ik even de site opnieuw wilde bouwen, het liefst 100% zelf, of met een ander systeem.

Ik nog proberen uit te leggen dat WP 60% van de CMS'en online is, en 27% van de sites.. Ik had inmidels de site opnieuw opgezet met andere plugins en alles dichtgetimmerd. Maar nee hoor, Wordpress was inherent rommel en onbetrouwbaar.
In de wereld van het web zitten helaas genoeg "digitale beunhazen" die écht geen idee hebben van waar ze mee bezig zijn. Wordpress is an sich een prima pakket, maar kan uit ervaring spreken dat er soms installaties tussen zitten die je (als hoster) het liefst niet op je server hebt, omdat die echt de hele boel openzetten voor alles en iedereen. En na dit een paar keer te hebben meegemaakt snap ik de opmerking "Wordpress is niet te vetrouwen" wel. Er zitten er een paar tussen die het voor de rest verpesten, waardoor er een algemeen beeld ontstaat dat Wordpress rommel is... Willen we meer, of minder Wordpress? :Y)
Ergens heeft diegene die in zijn oor gefluisterd heeft ook een punt. De site is gehacked omdat het op basis van wordpress was, geen security bevatte en een lekke plugin de oorzaak was. Dat is het hele punt en probleem met wordpress ook B)

Zet wordpress eens op een eigen server, gewoon een testpagina met test template, en hou de F5 knop maar eens (lang genoeg) ingedrukt. Je server crashed. Hoe kan dat?

Omdat wordpress by design ontzettend veel overhead bevat om een pagina te 'spawnen'. Je moet het maar net weten als serverbeheerder.

Daarnaast met 27% marktaandeel, worden die sites dus ontzettend vaak gescanned en potentieele exploits op losgelaten. Nogmaals; zat er GOEDE security in; dan gebeurde dat gewoon niet. Iedere goede techneut weet exact wat ik bedoel met welke stappen men neemt voor het afschermen van wordpress, het verwijderen van niet gebruikte templates en het bijhouden van plugins / thema's geinstalleerd op de website.

Het is een mooi product, gewoon lekker eenvoudig een site in elkaar klikken en "happy blogging" maar er komt nog veel meer bij kijken dan dat men denkt.

Ik heb 1 klant die enorme website op wordpress baseerd, ontzettend veel formulieren verwerkt en 'raar' opkijkt als er meer dan 48 javascript libraries meegeladen worden en de site nogal traag wordt bij de gebruiker.

Waarom kan men gewoon niet via een fatsoenlijke website bouwer een HTML website met formulieren in elkaar laten draaien, dat VEEL SNELLER en eenvoudig werkt dan dat wordpress ooit zal doen.
Waarom kan men gewoon niet via een fatsoenlijke website bouwer een HTML website met formulieren in elkaar laten draaien, dat VEEL SNELLER en eenvoudig werkt dan dat wordpress ooit zal doen.
Ik denk dat dat antwoord al is gegeven:
Wordpress is laagdrempelig, iedereen kan er mee aan de slag.

Bovendien zijn veel mensen gierig genoeg om Wordpress gratis te gebruiken en geen software te kopen waarmee je hetzelfde kan maken.

Gelukkig is er een hoster (Antagonist) die zelf ook e.e.a. in de gaten houdt.
Quote:
We helpen je door proactief te scannen op beveiligingslekken. Als we iets vinden, dan fixen we het. Zo voorkomen we misbruik van je website en e-mail. Dit doen we met Patchman. Deze software is ontwikkeld in het lab van Antagonist. Inmiddels staat het op zichzelf en wordt het wereldwijd gebruikt.
Hele grote sites gebruiken Wordpress. Zoals Wall Street Journal, forbes, TED.
Heb inderdaad wel eens gezien dat grote bedrijven Wordpress gebruiken maar 27% van alle sites is echt heel erg veel. Een vlugge google search leert mij dat er nu ruim 1.1 miljard webpagina's zijn. Dat zou betekenen dat bijna 300 miljoen op wordpress draaien.

Even er van uit gaan dat die 1.1 miljard aardig klopt.

[Reactie gewijzigd door L1nt op 24 november 2016 15:53]

Wij hebben ooit een aantal sites gehost die met Wordpress werkten. 1 van die sites had een lekke plugin draaien waardoor die site gehackt werd en die site onze server als spam-server gebruikte. In no time stond de server overal op de black list.

Tegenwoordig sturen wij klanten die met Wordpress willen werken naar: https://www.google.nl/?q=wordpress%20specialist
Je moet op de user zowiezo een mail limit instellen. Dat voorkomt dat als ie gehacked is er geen duizenden emails verstuurd kunnen worden.

Second; als je wordpress wilt draaien dat kan prima, maar je moet wel rekening met enkele zaken houden. En desnoods op serverniveau een patchmanager mee hebben draaien dat 'lekken' in sites 'afstruint' en desnoods eigenhandig 'patched'.

Zo kan een klant ook niet de mist in gaan door niet te updaten. Als laatst voor de bruteforce aanvallen; je moet op serverniveau een script mee laten draaien dat o.a apache status pagina afleest om de 5 seconden en POSTS naar xmlrpc.php, wp-login.php en /wp-admin/wp-admin-ajax.php maakt, om deze vervolgens AUTOMATISCH te laten blacklisten door je firewall.

Geen mens maakt meer dan 10 posts in 5 seconden als inlog poging in wordpress.
Tuurlijk kan het. Maar er zijn genoeg bedrijven die dat prima doen. Wij hebben werk zat, dus sturen we wordpress klanten naar andere bedrijven.
Wordpress is goed te beveiligen, maar zeker niet voor 100%. Welk OpenSource CMS is dat wel? Een hele goede plugin is: Hide My WP, te kopen voor een schamel bedrag in de shop van Envato. Hiermee wordt de basis van WordPress omgevormd (zelf in te stellen), waardoor bots en hackers niet meteen herkennen dat het een WP website betreft. Een goed update-beleid is daarnaast ook erg belangrijk, om ze tijdig lekken te dichten. Nee, WP is niet de veiligste keuze, maar wel een verrekte handig CMS met een grote diversiteit aan thema's en plugins. En, ook erg belangrijk, erg gebruiksvriendelijk met de wysiwyg pagebuilders die bij de meeste thema's wordt meegeleverd.
Er komt ook een stukje veiligheid van de webhosting kant bij kijken. Veel mensen staan er niet bij stil en kwakken er zonder bij na te denken Wordfence Security op en fingers crossed dat het goed zit. Terwijl er ook van de hosting kant al veel kwaadaardige requests afgevangen kunnen worden.
Als host kan je maar een beperkt aantal maatregelen nemen zonder de algehele performance en functionaliteit negatief te beïnvloeden. Zoals tig keer false positives in modsec voor elke scheet die je script maakt, dat moet je ook voorkomen. Vaak zoeken providers dan ook een beetje een balans op, dat is logisch - een deel beveiliging aan de server kant, maar er wordt ook geacht dat de scripts en plugins gewoon goed in elkaar zitten!

Je kan zeker maatregelen nemen, maar je kan nooit helemaal voorkomen dat een script gehacked wordt. Zeker niet met dit soort aanvallen waarbij de update servers dus zelf exploits zouden kunnen pushen naar alle sites die de software gebruiken. ;)
Ook daar zijn diensten / oplossingen voor (zelfs van Nederlandse bodem) die automatisch alle installaties scannen op malware/exploits en ze eventueel patchen.

Je kunt het natuurlijk nooit 100% voorkomen maar voor zover ik ervaren heb doen de meeste bekende webhosts niet veel aan, evenals het aanbieden van caching mogelijkheden of andere optimalisaties.

[Reactie gewijzigd door Ventieldopje op 24 november 2016 17:18]

En ook die zijn verre van dicht bij perfectie... Of er komen dingen door, of er worden dingen geweigerd die niet kwaadaardig zijn. Het allemaal afvangen is, zeker op shared hosting, nagenoeg onmogelijk. Dan kan je toch echt nog beter goede faq's schrijven over hoe mensen hun permissies, zowel op bestanden als database, goed moeten instellen... Dat scheelt pas echt veel. :P

En ja, veel hosts nemen te weinig tot totaal geen maatregelen. Helemaal mee eens. Ik vind alleen dat je hoe goed beveiligingsmechanismen zijn en hoe makkelijk beveiliging is in combinatie met usability iets te rooskleurig omschrijft.
Wordpress, het is best een leuk systeem (voor de gebruiker) maar zou eens opnieuw moeten worden gebouwd. De code is inconsistent plus een hoop bloat (en oude meuk). Dat plug-in systeem, vreselijk. Die updates zijn ook niet altijd even wenselijk omdat het fouten kan introduceren.

Ik heb nu een systeem bedacht waarbij je wordpress kunt verplaatsen op een (geheim) subdomein en via een html proxy de site kan tonen aan de bezoeker. Dat werkt a) vele malen sneller en b) Is het veel veiliger omdat men via de site niet kan inloggen e.d. Ook is de code geoptimaliseerd, goede cache en aan de code is niet te zien dat het om een wordpress site gaat dmv een filter. Kijk, dat is nog eens beveiligen :) Het mooie is ook, het is eigen code en hoef bijna niets te doen met de vreselijke code van wordpress.

[Reactie gewijzigd door Erwines op 24 november 2016 19:19]

Dat spreekt voor zich. Voor deze functionaliteit moet WordPress schrijfrechten op zijn eigen bestanden hebben. Daar gaat het al fout. Dat zou het niet moeten hebben, bij elke willekeurige exploit kun je dan een site platgooien. WordPress zou zichzelf moeten blokkeren als er nieuwe, niet geinstalleerde (security) patches gedetecteerd worden, niet proberen zichzelf te updaten.


Om te kunnen reageren moet je ingelogd zijn



Nintendo Switch Google Pixel Sony PlayStation VR Samsung Galaxy S8 Apple iPhone 7 Dishonored 2 Google Android 7.x Watch_Dogs 2

© 1998 - 2016 de Persgroep Online Services B.V. Tweakers vormt samen met o.a. Autotrack en Carsom.nl de Persgroep Online Services B.V. Hosting door True