#nocomment :-(

Als je nu nog drupal draait, wordt het hoog tijd om over te stappen naar wat anders.
Zelfs wordpress is beter, mits je auto-update aan hebt staan.

@ karakatau,

Ik vul het desnoods voor je in, maar we hebben het al honderdduizend keer herhaald en nog verandert er niets.
Dus +1...want ik durf het nauwelijks meer te zeggen

Nog een keer dus Drupal, Word Press, Magento (Does it ring a bell?) is insecure by design
Hoort u ons? Insecureity by design, en in de handen van de "non-professional" ronduit gevaarlijk speelgoed-CMS.

Dit alles in alle vriendelijkheid en vol begrip en respect aan u meegedeeld,.

luntrus

Klopt luntrus. Ik ken nog meer omgevingen waar een zelfde problematiek speelt. Informatieveiligheid als probleem.

Ik mis nog het recente artikel uit de Volkskrant. Dit aantal werd enkel voor het mkb Nederland gemeld.
https://www.volkskrant.nl/nieuws-achtergrond/honderdduizenden-sites-mkb-zijn-slecht-beveiligd-risico-op-diefstal-van-privacygevoelige-informatie-groot~b11871c7/

Als je zorgt dat je netjes op tijd de security updates installeert, is Drupal net zo veilig/onveilig als vergelijkbare projecten. Patches voor kwetsbaarheden met een potentieel grote impact worden ruim van tevoren aangekondigd, zodat je als beheerder de patchronde goed kunt inplannen en voorbereiden.

@ anoniem van 15:40

Juist en we moeten zeker volgens het bericht vaststellen, dat bij 215.000 + 115.000 Drupal websites dat niet gebeurd is.

Gaan we dan eens kijken bij deze sites, hoeveel ervan af te voeren jQuery bibliotheken draaien en anderszins veiligheid onder de maat is. Komt dat dan vanwege "onkunde", "lamlendigheid", "incompetentie" of "voor een dubbeltje op de eerste hosting-rang willen zitten"? We komen dan nog heel wat tegen.

Vertel eens, waarom worden er nergens op tijd de nodige updates en patches gedraaid, zeker als het niet automatisch gaat.

Hoe gaan we daar wat aan doen bij website eigenaren, admins en hosters en CDN's (professionelen, zowel als non-professionelen)?

Zeg het maar, ik weet het niet. We roepen het al jaren, maar er verandert niets. Er leert niemand op zo'n hardnekkige wijze als een mens, kennelijk. Het is al jaren aan de hand.

Met website security is het net als met roken, je stopt niet met onveiligheid eer er symptomen komen. Veiligheid ook meestal helemaal niets aan doen tot het een keer (flink) misgaat, zoals hier en dan, een verdwaasde blik en vaak ook nog wijzen naar anderen. Arrogant en nog wat, waarom eigenlijk?

luntrus

Het gebrek aan objectiviteit bij sommige "security experts" hier is tenenkrommend. Het gaat hier om een lek dat al lang gepatcht is. Dat beheerders hun software niet up-to-date houden is een ander verhaal en volstrekt niet gerelateerd aan welke omgeving dan ook.

@ soeperees

Sta toch meer aan de kant van Krakatau hier en op basis van 14 jaar dit soort websites met dit soort CMS doorspitten op website security en error gerelateerde zaken.

Er zijn wel degelijk issues, die gerelateerd zijn aan de op PHP gebaseerde CMS omgevingen.

Laten we een geniepig geinig frontend voorbeeldje geven: een "undefined object being passed via Require.js" - in bijvoorbeeld -wXw.kwetsbaar.com/static/version1524733074/frontend/Kwetsbaar/default/US/js/bundle/bundle2.min.js
(foutje in de module hoogstwaarschijnlijk - niet goed ge(pre)definieerd).

Haal het er maar weer uit op een website gepatcht of niet. Gevalletje persistente cross site scripting
Zie hier het bijbehorende dorkje: http://xss.cx/2011/07/20/ghdb/dork-xss-reflected-cross-site-scripting-javascript-injection-cwe79-capec86-example-poc-report-07202011-03.html

Met respect en niet om te bashen, hoor, doch Word Press, Drupal, Magento, te veel ellende gezien om deze omgevingen niet als eerste eens door te gaan lichten.

Alhoewel ik geef toe, niets is helemaal senang en overal is wel iets op aan te merken, als je echt de oren op de grond legt en je haar lang genoeg is, hoor je het gras echt wel groeien ;). En ook oude kwetsbaarheden kunnen in iets gewijzigde vorm weer de kop opsteken.

luntrus

Bij professionaliteit hoort ook dat je onderscheid kan maken tussen diverse technologieën. Ik doel hier op het feit dat PHP geen professionele programmeertaal is en beter niet voor professionele toepassingen gebruikt kan worden. Zoals luntrus al schrijft (+1) is er een rode draad te onderkennen bij al die problemen rond die populaire CMS'en. Persoonlijk vind ik Drupal nog een van de beste, zo niet de beste (maar een auto-updater zou mooi zijn). Echter, ook Drupal kan zich niet ontworstelen aan het PHP-drijfzand waarop het is gebouwd.

Onzin.

PHP is, net als ieder andere programmeertaal, prima te gebruiken om veilige code in te schrijven. Het probleem zit hem in de kennis en ervaring van de ontwikkelaar én een ontoereikend beleid. Waar het hier om gaat, is dat software ook onderhoudbaar en bij te werken moet zijn. Er gaat een moment komen dat er een lek wordt gevonden in jouw software. Het is belangrijk dat je als ontwikkelaar hierover nadenkt. Hoe ga je hiermee om? Hoe ga je zorgen dat gebruikers zo snel mogelijk weer veilig van jouw software gebruik kunnen maken?

Nee...


Dat het mogelijk is, dat weet ik. Zelf heb ik duizenden regels veilige PHP code (vnl. backend) geschreven. Het woord prima zou ik echter niet gebruiken. Eerder ondanks of met heel veel moeite.


Het echte probleem (de root cause) zit 'm erin dat PHP - als niet professioneel ontworpen programmeertaal - het de programmeur (nodeloos) moeilijk, bijna onmogelijk, maakt om veilige, onderhoudbare en bij te werken code te schrijven.


De eerste en belangrijkste beslissing die je als ontwikkelaar hierin kan nemen is om geen PHP te gebruiken. Kijk eens naar Java EE of - desnoods, als je geen problemen hebt met vendor lock-in, close source (delen open source gemaakt, echter Windows (desktop/classic) runtime and framework nog steeds closed source), etc. - C# ASP.NET.

@ anoniem van 9:36

Net als javascript destijds, was PHP (nog) niet klaar voor gebruik op Interwebs. Bedenk dat je steeds cheat sheets dient te gebruiken om niet in de bekende valkuilen te belanden. Welke? Kijk eens wat er op de speciale PHP scanner van Sucuri website beveiliger zoal langskomt.

Kijk ook wat je kunt doen gewapend met een weak PHP woordenboek binnen server mapscanners. Als developer moet je dus a.h.w. als de website een kleurboek zou zijn, met PHP heel netjes binnen de lijntjes blijven kleuren met feitelijk te dikke stiften in de hoop geen "vlekkerig geheel" te krijgen.

Laatst kreeg ik een "gelikte" professionele website onder ogen, die in Nederland gebouwd was met Magento voor een webshop van een groot Zwitsers wereldmerk horloges. De website was zogenaamd veilig want via Magereport aangemerkt als low risk site. Toch kwam bij Mozilla de site niet verder als een C+ status en met aanbevelingen. Er waren 3 af te voeren jQuery bibliotheken, error: undefined variable require & error: undefined function require.config , aangetroffen in front-end JS bundle; Zwakheden: strict-transport-security - max-age=300 - geen best policy gevolgd, Page meta security headers niet veilig ingesteld - secure attributes niet gezet met cookie security options, HTML forms not veilig ingesteld.

Domein kon door verkeerde certificaatinstellingen worden gehijacked, HSTS header niet goed insteld, dus MiM-aanvallen mogelijk. E-mail fraude mogelijk door .SPF not aanstaand, DMARC niet aanstaand, DNSSEC sond op "false".

Ga je lekker met je top-site ontwerp. Uit mijn ontmoetingen met studenten van de IT opleidingen bij een Hoge School (SEC-INF & SEC-TINF) zie ik als proctor met relevante kennis hoe security wel wat meer aandacht krijgt, maar het jQuery all sorts (net als Engelse drop) probleem) nog lang niet getackled is. Wanneer gaan we hier bij de opleidingen eens meer werk van maken? Oh even een zwak PHP scan overzichtje:
Krakatau's mening is dus zeker niet geheel ongefundeerd, berust niet op PHP bashing en is verklaarbaar. Lees anders eens op StackOverflow, o, het search string overzichtje komt van Github en StackOverflow, info credits daarvoor. Github is nu inmiddels verworven door Microsoft.

luntrus

@ de ontkenners of twijfelaars van wat wij beweren,

Geloof je het allemaal nog niet, wat o.a. Krakatau en luntrus je proberen te vertellen,
dan kun je je hier eens nader in gaan verdiepen:
https://www.aldeid.com/wiki/Category:Digital-Forensics/Browser-based-Malwares/JavaScript

Info credits - Content is available under GNU Free Documentation License 1.3 or later unless otherwise noted.
Deze info is uit 2014, maar nog hoogst actueel. Ik zie ze nog elke dag voorbij komen
(SUSPICIOUS -exceeding max runtime etc. etc.)

En wat PHP betreft: http://www.prophethacker.com/2016/01/php-cheat-sheet-for-developers.html
Info credits go out to Vinay Kumar.

luntrus

Er is een wezenlijk verschil tussen programmeertalen en frameworks.

@luntrus: de zaken die jij aanhaalt zijn zeker niet onbelangrijk, maar deze hebben niks met de programmeertaal te maken, en daar hadden we het hier over, toch? Magento kiest ervoor om verouderde JavaScript libraries te gebruiken want zij achten het risico klein dat fouten hierin te misbruiken zijn. Magento kiest ervoor om standaard geen veilige cookieinstellingen te gebruiken (kan je overigens wel veilig maken door wat instellingen aan te passen). De overige zaken die je benoemd zijn grotendeels serverinstellingen en hebben al helemaal niks met een programmeertaal te maken.

Iedere taal, ieder framework heeft valkuilen. Een ontwikkelaar die een framework als Magento, Drupal of wat dan ook gebruikt dient hiervan op de hoogte te zijn. Dat geldt voor Magento, maar evengoed voor Java EE of ASP.NET applicaties. Een goede ontwikkelaar leest de documentatie en weet wat die valkuilen zijn. En ja, sommige frameworks bieden meer aandacht aan security en zullen out-of-the-box veiliger zijn. Maar het kost slechts één foutje van de ontwikkelaar om deze veiligheid om zeep te helpen...