'Veel mkb-websites zijn kwetsbaar voor toegang tot database met klantgegevens'

Driekwart van de meer dan een half miljoen mkb-websites zijn volgens onderzoek slecht beveiligd. Bij een op de vier is er een risico dat er toegang verkregen kan worden tot databases met persoonsgegevens.

Dat betekent dat bijna honderdduizend websites van het midden- en kleinbedrijf vatbaar zijn voor misbruik waarbij persoonsgegevens benaderd kunnen worden door kwaadwillenden. De cijfers blijken uit onderzoek van internetanalist Dataprovider.com, dat werd uitgevoerd in opdracht van De Volkskrant.

Het bedrijf analyseert maandelijks 3,2 miljoen Nederlandse sites en kijkt daarbij onder andere naar de mate waarin persoonsgegevens verwerkt worden, de softwareversies waar de site op draait, of de verbinding via tls verloopt en het al dan niet openstaan van poorten. Volgens Gijs Barends van Dataprovider.com kijken kwaadwillenden hier ook naar als ze sites willen kraken: "Sites met dit soort beveiligingsgebreken zijn laaghangend fruit voor hackers."

De Volkskrant liet het onderzoek uitvoeren vanwege de invoering van de AVG, die maakt dat bedrijven aan strengere regels en toezicht onderworpen worden bij het beschermen van persoonsgegevens. "Ook kleinere bedrijven hebben databases met soms heel gevoelige persoonsgegevens", volgens Lokke Moerel, lid van het adviesorgaan de Cyber Security Raad.

Reacties (96)

[MSalters]

Je zou toch hopen dat een tech site als Tweakers beter weet dan het overschrijven van oude media zoals de Volkskrant.

Er worden een hele verzameling van issues door elkaar gegooid. "Geen HTTPS" is een relevante zorg, Dat wil niet zeggen dat daarmee toegang verkregen kan worden tot een database met persoonsgegevens. Sterker nog - hoeveel sites hebben uberhaupt een database met persoonsgegevens?

Het lijkt erop dat een klein onbekend bedrijfje een persbericht naar de Volkskrant heeft gestuurd, met een goede timing vanwege de AVG. Slim, dat is gratis reclame.

[Ma_rK]

Ik kan wat slecht tegen deze aannames.

Dataprovider indexeert -net als Google- het web. Het verschil is dat het dat data gestructureerd aanlevert. Dataprovider doet dit voor de grote merken van het internet. Dat jij deze prachtige Nederlandse scaleup niet kent, omdat ze geen B2C merk zijn en alleen werken voor die grote merken, maakt je aanname "onbekend klein bedrijfje" niet juist. De Volkskrant is een kwaliteits medium en zal haar partners bij zo'n onderzoek nauwkeurig selecteren. Juist omdat Dataprovider alleen werkt voor de grote merken hebben ze ook niets aan dergelijke publiciteit. Daar krijgen zij geen klanten door. Dat maakt de motieven des te zuiverder.

Dan over de inhoud van de data.

Dataprovider kijkt niet alleen naar HTTPS en "heeft de site een contact formulier", maar vooral "welk CMS draait er", "is deze up to date", "waar wordt de site gehost", "is dit een legitieme webshop" etc. Op basis van die data weet Dataprovider onwijs goed hoe veilig het web is en werkt daarin samen met instanties om het web veiliger te maken (waarvoor hulde).

Tot slot wordt bv een contactformulier (vaak via http) in een Joomla, Wordpress etc gewoon in de database opgeslagen en via mail verstuurd. Als je dan ziet hoe veel van die sites niet up to date en dus niet veilig zijn en hoe weinig hosters gebruik maken van diensten als Patchman, dan vind ik de gemaakte claim niet alleen juist, maar buitengewoon waardevol want dit maakt het internet veiliger. Binnen de nieuwe AVG zit je daarmee namelijk al snel aan een datalek.

[Reactie gewijzigd door Ma_rK op 23 juli 2024 03:06]

[Helium-3]

Goed gesproken ;-)

[dcm360]

Als je de definitie van persoonsgegevens pakt dan denk ik dat best veel sites persoonsgegevens verwerken. Enkel al het hebben van een contactformulier zorgt ervoor dat bezoekers zaken als e-mailadres of telefoonnummer kunnen laten verwerken door een site. Hierbij is het hebben van https noodzakelijk, dus het ontbreken ervan is een tekort.

Het is dus één van de issues (niet de enige) die aangestipt wordt, en relevant is. Daarnaast wordt vermeld dat de Volkskrant de opdracht heeft gegeven, waarmee het al wat minder lijkt op een publiciteitsstunt van de onderzoeker.

[Twanekel]

Ik denk niet dat die contactformulieren alles opslaan in een database, het niet gebruiken van https is echter wel een issue

[jrswgtr]

Veel websites zijn gebouwd op WordPress. De meeste Wordpress sites gebruiken Gravity Forms voor (contact)formulieren. Gravity forms slaat wel degelijk alle entries op in de database.

-- edit --

Dit zelfde Gravity Forms kan ook een kwetsbaarheid vormen. Als er in een formulier een bestands upload veld zit kunnen kwaadwillenden hacking scripts uploaden (mits de server de beveiliging niet op orde heeft). Is bij ons wel eens gebeurd, dat een site van een klant is overgenomen op deze manier.

[Reactie gewijzigd door jrswgtr op 23 juli 2024 03:06]

[Twanekel]

Gebruik zelf op een website Contact Form 7, zelfde issues?

We gebruiken het bestands upload veld niet, scheelt al

[psychodude]

File uploads zijn altijd een security risk, je staat een buitenstaander namelijk actief toe om bestanden naar eigen maak naar je server toe te versturen. Met daarbij alle mogelijke gevolgen van dien. Zelfs al doe je de afhandeling hiervan conform de huidige veiligheidsstandaarden, blijft er altijd het risico bestaan dat dit bij de gebruikte server techniek, bijv. PHP, niet waterdicht is.

Met contact velden alleen is dit risico er ook altijd aanwezig, ook hierbij laat je een buitenstaander namelijk de kans hebben om gebruik te maken van kwetsbaarheden. Zelfs bij up to date software, bestaat er nog altijd de kans dat niet eerder bekende kwestbaarheden misbruikt kunnen worden.

Afhankelijk van de soort website en verwerkte gegevens kun je dan ook overwegen om dit soort contactformulieren via een 2e webserver te laten verwerken. Losstaand van de overige gegevens van de persoon. Daarnaast moet je je natuurlijk altijd afvragen wat je sowieso qua persoonsgegevens registreert. Maar ook voor hoe lang 'direct' verbonden met het web.

Als ik bijv. als klant product X bestel bij winkel A, dan is het eigenlijk overbodig voor de database die gebruikt wordt voor website A om mijn volledige adres en volledige naam te registreren. Ik weet zelf namelijk maar al te goed deze info. Een systeem waarbij deze bestellingen tijdelijk worden weggeschreven naar een tweede database tot afhandeling en vervolgens na afhandeling terecht komt binnen een database server niet via een direct interface (incl. dus website) verbonden met het web zou een betere optie zijn.

Dit soort systemen brengen uiteraard extra kosten met zich mee. Een enkele server als MKB met alle gegevens binnen een dezelfde database en zelfs fysiek ook nog eens op dezelfde hardware als de webserver is fysiek een stuk goedkoper. Komt dan nog eens bovenop dat maintenance van de productcode tijd en dus geld kost, ook al beperkt dit zich tot het draaien van updates. En als laatste het probleem van software / scripts die gebruikt blijven worden die niet langer worden bijgewerkt. En daarmee dus ondanks dat de gebruikte scripting taal wordt bijgewerkt, hierin nog onveilige functies blijven gebruiken.

[Verwijderd]

Bestanden uploaden en chmod 0640. Kan ie niet zo maar executen

[Josk79]

Helpt niet tegen bijv. .php files.

[Josk79]

Blijft lastig om waterdicht te implementeren, die "tweestapsraket". Er dient een interface te bestaan tussen de 'publieke' server en de 'private' server. Als de publieke server gehackt is en de aanvaller er dus toegang toe heeft, maakt het eigenlijk niet meer uit dat de private server niet aan internet zit, want hij kan er dan toch op afstand bij.

[Archcry]

Het niet gebruiken van HTTPS stelt een derde partij wel in staat om een man in the middle attack uit te voeren en daarmee de gegevens te bemachtigen van de gebruiker die het formulier invult. Wanneer dit gegevens zoals naam, telefoonnummer en/of email adres zijn dan heb je al te maken met de AVG.

Edit: Het kan zelfs al zonder man in the middle, gewoon onbeveiligde wifi netwerken van restaurants en andere openbare plekken afluisteren.

[Reactie gewijzigd door Archcry op 23 juli 2024 03:06]

[GMJansen]

Joomla, Drupal en Wordpress slaan alles op in de database.
Op de webserver staat géén data.

2 uitzonderingen: back-ups en documenten/ foto's

@Twanekel laat maar, Ik las je post niet goed. Het ging je om óf het opgeslagen werd

[Reactie gewijzigd door GMJansen op 23 juli 2024 03:06]

[DigitalExorcist]

Precies dat. En al zou je wél HTTPS hebben, dan nóg zegt dat niks over het bedrijf en hoe het met zijn database met klantgegevens omgaat.

Natuurlijk is het wél zaak om je webhosting op orde te hebben met actuele versies, een goed beleid daaromtrent te hebben, et cetera. En dat dat vaak niet gebeurd is evident. En dat mag ook best onder de aandacht gebracht worden.

[Cergorach]

Natuurlijk is het wél zaak om je webhosting op orde te hebben met actuele versies, een goed beleid daaromtrent te hebben, et cetera. En dat dat vaak niet gebeurd is evident. En dat mag ook best onder de aandacht gebracht worden.

Het is niet de eerste keer dat iemand de software (versie) van hun website 'vervalst', dat er staat dat het op PHP-Nuke 5.5 draait, betekend nog niet dat het zo is (wellicht slecht voorbeeld ;-). Aanvallers gaan vervolgens proberen om de verkeerde exploits te gebruiken op je website (vaak geautomatiseerd).

[kozue]

Versienummers in open source kun je sowieso nooit op vertrouwen voor het vinden van exploits. Vaak blijven die hangen op wat er bij de distro kwam op het moment van release, maar krijgen ze wel fixes voor beveiligingsproblemen.
Hoe vaak ik al wel niet bezorgde mailtjes heb gehad van niet zo ervaren systeembeheerders die zo’n suffe PCI scan hebben gedraaid waarin stond dat onze OpenSSH versie lek is omdat het versienummer te laag was...(sowieso zijn die scans vooral bedoeld om geld in het laatje te brengen door beheerders bang te maken met onzinnige nitpicks, maar dat terzijde)

De enige manier om er achter te komen of iets echt lek is, is door het lek uit te proberen. En dat kan best zonder iets kapot te maken (je hoeft niet perse meteen een DROP TABLE te doen, met SELECT kom je er ook wel). Net zoals die proof-of-concepts van windows lekken die gewoon alleen notepad openen om aan te tonen dat ze willekeurige programma’s kunnen starten. Maarja, dan heb je security experts nodig en die zijn duurder dan een paar script kiddies inhuren die even de openssh headers parsen

[d3burt]

Precies. En dat is dus ook precies wat het geboefte doet. Mijn website draait static pages onder lighttpd, en heeft niet eens PHP geïnstalleerd. Ik zie in de logs aanvallen op Wordpress, Joomla, Magento, op alle OWASP10 zwakheden, en zelfs op .aspx. Aanvallers denken echt niet, "goh, volgens het versienummer van Apache is deze server niet kwetsbaar, dus laten we deze server overslaan".

[Helium-3]

> aanvallers denken

Bedoel je volledig geautomatiseerde serverracks in China die elk ip adres met open poort 80 / 443 scannen met bekende exploits ongeacht de versie ?

Dat is geen nadenken, dat is gewoon brute force

[DigitalExorcist]

Daarom is het ook een goed idee headers van je mails zoveel mogelijk aan te passen. Geen referenties naar interne adressen of hostnames of versienummers mee te geven. Als je desnoods al poort 25 voor mail moet gebruiken, pas dan de begroeting aan die je via telnet krijgt naar iets algemeens en niet herleidbaar naar mailserver-versies e.d.

Security through obscurity alléén is een doodzonde, maar als éxtra laag bovenop je bestaande beleid kan het geen kwaad.

[TweakerPas]

Helemaal mee eens, het grote gross slaat niet eens wat op in de database van de website m.b.t. bezoekers. Deze bevatten puur wat informatie pagina`s en wellicht een contact / offerte formulier.

Als je als onderzoek dan wat voeten in aarde wil hebben, spreek dan over onderzoek naar webshops!

[Archcry]

Wanneer er voor het contact formulier / offerte formulier persoonsgebonden data opgeslagen wordt in een database dan spreek je wel degelijk van het verwerken van persoonsgegevens. Wanneer je kritisch gaat kijken naar de AVG dan blijkt dat iets al vrij snel een persoonsgegeven is.

[TweakerPas]

Idd wanneer, en ik gaf juist aan dat het bij contact en offerte formulieren in de meeste gevallen dus NIET opgeslagen wordt en dus het onderzoek geen voeten in aarde heeft. Je kunt niet luk raak websites zogenaamd gaan testen zonder überhaupt te weten of ze wel data opslaan. Bij webshops weet je het i.i.g. zeker.

[Archcry]

Zelfs wanneer de gegevens van zo'n formulier niet opgeslagen worden is het nogsteeds wel van belang dat de website over HTTPS beschikt. Anders zijn de verzonden gegevens nogsteeds zichtbaar voor de mensen op hetzelfde netwerk. En aangezien elke huis, tuin en keukentrudie die een eigen restaurantje heeft vaak ook een onbeveiligd of slecht beveiligd wifi netwerk heeft voor haar gasten is het nogsteeds aan de eigenaar van de MKB website om zijn HTTPS fatsoenlijk op orde te hebben.

Ik zeg overigens niet dat bovenstaande scenario vaak voorkomt, maar het is toch zeker wel laaghangend fruit voor iedereen die een beetje verstand van computers en kwade bedoelingen heeft. Even lekker een middagje met een biertje op een terrasje persoonsgegevens binnenhengelen.

[Reactie gewijzigd door Archcry op 23 juli 2024 03:06]

[DdeM]

In de meeste gevallen wordt data just wel opgeslagen. De meeste formulier plugins voor de meest favoriete cmd systemen slaan juist de data op zodat je simpel de status kan managen en data niet verloren gaat als er bijvoorbeeld storing is bij een mail server. Je zal als bedrijf niet blij worden als je er achter komt dat je potentiële klanten mist omdat je systeem de ingevulde formulieren niet fatsoenlijk verwerkt.

[Stoelpoot]

Het enige deel waar ik HTTPS / TLS gebruikt zie worden, is bij een uiteenzetting van de werkwijze van Dataprovider.com, zoals beschreven door Gijs Barends. Dit heeft er dus niets mee te maken of dit wel of geen risico vormt.

Dataprovider.com had ook kunnen controleren of er afbeeldingen van bananen op de pagina stonden, en dan had dat ook op bovenstaand beschreven manier in de tekst gestaan. Volledig onzin natuurlijk om daar conclusies uit te trekken, maar nog steeds volledig correct als het op die manier in het nieuwsbericht stond.

[Brousant]

Overschrijven doen ze ook niet, ze melden keurig dat het hier om berichtgeving van de Volkskrant gaat, en de titel is door middel van aanhalingstekens gekentekend als citaat. Dus dat Tweakers hier klakkeloos beweringen zou overnemen zie ik niet zo.

[wica]

Wat valt er over te tikken van het Volkskrant artikel? Er staat niets in dan naar schatting.
Heb ook het idee, dat dit eerder een reclame stuntje is van Dataprovider.com.

[hakog2]

Nou, als bijvoorbeeld de Wordpress login pagina wordt benaderd zonder Https dan is dit wel degelijk van belang voor de bescherming van persoons gegevens. Ben het wel met eens dat het allemaal een beetje makkelijk is opgeschreven.

[atlaste]

Dat ja.

Sportverenigingen, scholen, huisartsen, tandartsen, fysiotherapeuten en kinderdagverblijven verwerken privacygevoelige gegevens van klanten. Denk aan telefoonnummers, rekeningnummers, burgerservicenummers, paspoortgegevens of gegevens over de gezondheid van cliënten. Een gemiddelde Nederlander zit in honderden, soms duizenden databases.

Kom nou. Wat even plat wordt geslagen in het artikel is dat wordt gekeken naar de website en vervolgens de conclusie wordt getrokken dat alle persoonsgegevens van die organisatie dan waarschijnlijk te hacken zijn.

Het is echt complete bullshit. Als je bijvoorbeeld kijkt naar huisartsen, fysiotherapeuten en kinderdagverblijven, hebben die vaak deze systemen vrijwel altijd fysiek gescheiden staan. In veel gevallen wordt die software door derde partijen gebouwd, die hun zaakjes prima op orde hebben.

Van kinderdagverblijven weet ik toevallig dat De Correspondent een tijdje geleden op zoek is geweest naar lekken in de apps en welke persoonsgegevens verstuurd werden. Ik heb zelf toen ook even een app geprobeerd uit elkaar te trekken voor wat research voor ze... uiteindelijk heb ik inderdaad een theoretische kwetsbaarheid gevonden in de app in kwestie, maar deze was dermate vergezocht dat het absoluut geen risico was. Bottom line zit het over het algemeen wel goed en worden er helemaal niet zo veel persoonsgegevens verstuurd. Na delen van de resultaten met DC, werd deze conclusie later ook vanuit DC bevestigd, die samen met wat white hat hackers tot dezelfde conclusie waren gekomen.

Fysiotherapeuten en huisartsen hebben meestal ook gewoon fysiek de systemen gescheiden. Bij mijn broer bijv. staat de server hiervan gewoon op de praktijk en deze is niet beschikbaar vanuit het internet. Sterker nog, zo wordt het ding geinstalleerd en wel opgeleverd. Logisch toch?

E-mail verkeer dan? Ook dat wordt vaak uitbesteed bij professionele bedrijven, zoals Zorgmail. Wederom niet zo raar, want de meeste van dit soort instanties willen helemaal geen mailserver beheren...

Dit hele artikel is volgens mij gewoon stemmingmakerij.

[johnkeates]

Tsja, het artikel hoeft niet correct te zijn om gelijk te hebben he. Als je gewoon een random bende NL sites door sqlmap gooit heb je zo complete databases, zo positief is het allemaal helaas niet. TLS heeft er weinig invloed op, tenzij je WiFi hotspots zonder encryptie als vector neemt (en ja, dat zijn er genoeg).

HTTP + Wifi van NS of van Starbucks of McDonalds en je kan lekker de hele dag accounts scrapen. En als je geen zin hebt het zelf te doen verstop je een pineapple met LTE dongle en ga je op een terras zitten.

[Reactie gewijzigd door johnkeates op 23 juli 2024 03:06]

[totaalgeenhard]

Baitclick titel zegt al genoeg.

Als ze daadwerkelijk pogingsdelict hadden gedaan was enige redding betreffende bedrijven te informeren.

Maar aangezien ze niets weten en zich baseren op aanname kan men niet eens de claim MKB onderbouwen. Tenzij meer vanuit gaan de leeuwendeel van domeinnamen in gebruik zijn door MKB.

Bovendien NAW gegevens zijn niet de primaire reden om een "site" aan te vallen aangezien je die gegevens en zeker nu niet zomaar kan gebruiken.

[0xygen500]

Ze zullen vast gedacht hebben, dit is van onze collega's bij de persgroep dit zit wel snor.

[CAPSLOCK2000]

Ik snap niet dat we geen miljarden investeren in digitale veiligheid.
Dat meen ik, miljarden. Bezuinig maar op snelwegen en steek het in onze digitale infrastructuur.
(Onze fileprobleem krijgen we toch niet opgelost, het is al lang en breed uitgerekend dat het niet haalbaar is. Maar daar wil ik nu geen discussie over hebben).

Het hele bedrijfsleven heeft last van dit probleem. Het is misschien niet direct zichtbaar maar het drijft de kosten enorm. Je kan nooit op je IT vertrouwen, alles rammelt en bij het minste gaat het fout. Daardoor is er een enorme weerstand om dingen beter te maken uit angst dat er iets stuk gaat en niemand weet hoe het hersteld kan worden. Daardoor zijn er tal van inefficiente systemen en worden een hoop dingen gewoon niet gedaan. De gemiste kansen zijn eindeloos.

Losse bedrijven, zeker in het MKB, krijgen dit niet opgelost. Daarvoor is het probleem veel te groot, complex en verweven. Net zo min als de buurtsuper om de hoek zelf een snelweg kan aanleggen naar het distributiecentrum. Dat moeten we als groep doen.

[mkools24]

Ik denk dat die miljarden wel beter te besteden zijn bijv aan zorg of meer alcoholcontroles of andere zaken. Zolang jan en alleman een site kan opzetten ga je dat probleem met een miljardeninvestering ook niet oplossen.

En je weet hoe dat gaat hier, steek ergens 3 miljard in en 2.5 miljard ben je al kwijt aan overhead, allerlei adviseurs en commissiebureaus en weet ik wat nog meer.

Kijk naar de aardbevingen in Groningen waar ook miljarden in wordt gestoken, al dat geld gaat ook op aan overhead en heel veel mensen vullen hun zakken daarmee maar er is nog geen steen gelegd.

[CAPSLOCK2000]

Zolang jan en alleman een site kan opzetten ga je dat probleem met een miljardeninvestering ook niet oplossen.

Jan en alleman moeten het gereedschap krijgen om het goed te doen. Het is nu veel te moeilijk. Je moet zo veel kennis hebben dat eigenlijk niemand het kan. Zelfs met een heel team aan IT'ers is het onmogelijk om overal aan te denken. We hebben een degelijke basis nodig zodat niet iedereen voor ieder project het wiel opnieuw moet uitvinden.

En je weet hoe dat gaat hier, steek ergens 3 miljard in en 2.5 miljard ben je al kwijt aan overhead, allerlei adviseurs en commissiebureaus en weet ik wat nog meer.

Laten we er geen discussie van maken over het afschaffen van de overheid of het invoeren van anarchie.

[mkools24]

Meeste MKB sites gebruiken vaak toch iets als Wordpress als basis. Dan moet je daarin investeren om zulke oplossingen makkelijker en veiliger te maken maar dat hoeft echt geen miljarden te kosten hoor, dat kan ook wel met een paar ton, of misschien miljoenen als je gaat investeren in 90% van dat soort standaard apps.

[sassymousasi]

Het is een keuze om alles via adviseurs, commissiebureaus en weet ik wat nog meer te laten lopen. Er bestaat namelijk ook een optie om deze rompslomp er gewoon uit te slopen.

Na een fusie, waarbij ik als bedrijf een beetje de ins en outs van het besteden van geld door de gemeente van dichtbij te hebben meegemaakt vind ik het niet zo gek dat driekwart van het geld niet goed besteed wordt. Iedereen kloot maar wat aan.

Overheid moet zo klein mogelijk blijven/worden anders wordt er zo ontzettend veel geld verspild, letterlijk verspild.

De overheid had letterlijk, letterlijk gewoon de mensen in Groningen direct af te kunnen betalen en dan waren ze nog steeds goedkoper uit dan nu met alle narigheid die er de afgelopen jaren naar voren is gekomen. Met commissies die elkaar controleren waarvan de bron altijd weer direct naar Shell is door te leiden. De overheid is allang niet meer de overheid, het wordt gecontroleerd door de grote bedrijven.

[Reactie gewijzigd door sassymousasi op 23 juli 2024 03:06]

[Verwijderd]

Wat wil jij dan gaan doen met die miljarden? Digitale veiligheid is een heel breed begrip, te breed zelfs.

Als de overheid er dit al aan zou uitgeven dan krijg je weer allerlei vage bedrijfjes die graag uit de ruif eten, en vervolgens is er over een paar jaar maar een marginale verbetering.

[CAPSLOCK2000]

Wat wil jij dan gaan doen met die miljarden? Digitale veiligheid is een heel breed begrip, te breed zelfs.

Daarom is er ook zo veel geld nodig. Ik wil het (deels) uitgeven aan het bouwen van betrouwbare basiscomponenten waar je op kan vertrouwen, en het ontwikkelen van tools die helpen bij veilig programmeren. Uiteraard moet de minister dat niet zelf gaan doen maar uitbesteden aan experts en wetenschappers, maar dat geldt voor alles wat de overheid doet.

Als de overheid er dit al aan zou uitgeven dan krijg je weer allerlei vage bedrijfjes die graag uit de ruif eten, en vervolgens is er over een paar jaar maar een marginale verbetering.

Dat kun je zeggen over alles wat de overheid doet, dat is geen argument. Zolang er een overheid is die onze centen verdeeld vind ik dat we een (groter) deel van de pot moeten uitgeven aan IT-veiligheid en dan met name aan fundamenteel onderzoek.

[reneflo]

Je reactie lezend denk ik dat je met 'we' de overheid bedoelt? Ik ben heel benieuwd hoe jij dat wil gaan uitgeven. De enige manier die ik zie die enigszins een oplossing kan zijn is een bedrijf oprichten en alle MKB bedrijven verplichten om door dat bedrijf een website te laten bouwen en verbieden er zelf één te hebben.

MKB bedrijven hebben gewoon een website nodig voor hun vindbaarheid, maar hebben te weinig kennis en geld om dit vooral over een langere termijn perfect te regelen. Als je MKB'ers subsidie gaat geven om een jaarlijkse security check te doen ofzo betekent het nog niet dat dit ook gebeurt en dat er wat verbetert. Ik zie dan eerder gebeuren dat dit geld naar de buurjongen gaat die hooguit even wat dingen update, er dan achter komt dat er iets stuk gaat en dan zit de ondernemer weer even zonder website.

[CAPSLOCK2000]

Je reactie lezend denk ik dat je met 'we' de overheid bedoelt? Ik ben heel benieuwd hoe jij dat wil gaan uitgeven.

Met 'we' bedoel ik alle inwoners en bedrijven van Nederland en die worden inderdaad vertegenwoordigd door de overheid.

De enige manier die ik zie die enigszins een oplossing kan zijn is een bedrijf oprichten en alle MKB bedrijven verplichten om door dat bedrijf een website te laten bouwen en verbieden er zelf één te hebben.

Ik ben meer van de wortel dan van de stok. Ontwikkel tools die zo goed zijn dat mensen ze willen gebruiken. Ok, makkelijker gezegd dan gedaan, maar dat is waarom het miljarden gaat kosten. Als dat te moeilijk is kun je ook een hoop goeds doen met training en voorlichting.
Sponsor cursussen veilig programmeren, subsidieer het werk van security researchers, laat TNO of een ander onderzoeksinstituut werken aan tools om bugs te vinden of te voorkomen, richt een keurmerk op zodat je de goede IT'ers van de slechte kan scheiden.

MKB bedrijven hebben gewoon een website nodig voor hun vindbaarheid, maar hebben te weinig kennis en geld om dit vooral over een langere termijn perfect te regelen. Als je MKB'ers subsidie gaat geven om een jaarlijkse security check te doen ofzo betekent het nog niet dat dit ook gebeurt en dat er wat verbetert. Ik zie dan eerder gebeuren dat dit geld naar de buurjongen gaat die hooguit even wat dingen update, er dan achter komt dat er iets stuk gaat en dan zit de ondernemer weer even zonder website.

Dat is niet hoe ik het zou doen, maar het kan. Als je geld geeft moet je daar echter wel consequenties aan verbinden. Dan moet je gaan controleren of de sites veilig zijn en boetes uitdelen als het niet zo is. Dat zou te veel gedoe zijn. Misschien kun je bedrijven subsidie geven als ze zelf ook investeren.

[reneflo]

Als alle inwoners en bedrijven van Nederland meer moeten investeren betekent niet perse dat de overheid dat moet doen. Bedrijven moeten winst maken en die zien beveiliging puur als kosten. Voor mijn gevoel wordt programmeren als steeds makkelijker met tools die ook makkelijker veilig te maken zijn. Zoveel bedrijven hebben bijvoorbeeld een standaard Wordpress site die zichzelf up to date kan houden. Als je het automatisch updaten dan uit zet is dat nut alleen direct weer weg. Als bedrijven die tools maken die makkelijk te installeren zijn en zichzelf goed veilig houden en dat ook goed kunnen verkopen als unique selling point zou de digitale wereld zelf wat veiliger moeten worden zonder dat de overheid hier miljarden aan hoeft uit te geven. Probleem blijft dat hier weinig prioriteit ligt en dat ga je ook niet oplossen met gratis cursussen, IT keurmerken of betere tools.

[CAPSLOCK2000]

Als alle inwoners en bedrijven van Nederland meer moeten investeren betekent niet perse dat de overheid dat moet doen.

Niet per se, maar over het algemeen werkt het wel zo met grote kosten die we samen moeten dragen en waarbij niemand zich individueel verantwoordelijk voelt. De afsluitdijk hebben we ook niet overgelaten aan inwoners en het bedrijfsleven.

Bedrijven moeten winst maken en die zien beveiliging puur als kosten.

Dat is het ook, die gaan er dus ook niks veranderen als ze het kunnen ontwijken.

Voor mijn gevoel wordt programmeren als steeds makkelijker met tools die ook makkelijker veilig te maken zijn.

Dat is ook zo, maar het gaat erg langzaam. Mijn oproep is dat we in dit soort tools moeten investeren zodat het makkelijker wordt om goede software te maken.

Als bedrijven die tools maken die makkelijk te installeren zijn en zichzelf goed veilig houden en dat ook goed kunnen verkopen als unique selling point zou de digitale wereld zelf wat veiliger moeten worden zonder dat de overheid hier miljarden aan hoeft uit te geven.

Als. Maar de meesten doen dat niet, want dat vereist een lange termijn investering.

Probleem blijft dat hier weinig prioriteit ligt en dat ga je ook niet oplossen met gratis cursussen, IT keurmerken of betere tools.

Er zijn geen toverstokken. Betere tools en meer kennis zijn deel van de oplossing, net als regelgeving, maar geen enkele individuele maatregel zal alle problemen oplossen. We kunnen hooguit sturen.

[reneflo]

De afsluitdijk of de deltawerken zijn inderdaad een super goed voorbeeld voor wat de overheid moet doen. Als we in Nederland een muur om ons internet kunnen bouwen en we dan veilig zijn voor alle slechte dingen zou dat inderdaad iets kunnen zijn wat de overheid in moet investeren, alleen dat kan niet.
De wegen komt al iets dichterbij als analogie, maar dat is meer te vergelijken met de kabels in de grond. De wegen zouden net zo gefinancierd kunnen worden als de kabels, alleen dan moet je overal tol gaan heffen voor gebruik en wordt aanleggen veel moeilijker, dus doen we niet. Internet kabels waren in eerste instantie ook door (semi-)overheidsinstellingen aangelegd.

De verantwoordelijkheid voor de veiligheid van je eigen producten is toch echt iets wat ik liever aan mensen zelf overlaat en die ik absoluut niet wil dat die bij de overheid komt te liggen. Ik ga toch ook geen subsidie aanvragen als ik een slot op mijn voordeur wil? Probleem is hier dat als hier ingebroken wordt dat bedrijven producten van anderen verliezen, maar banken krijgen toch ook geen overheidssteun als jij daar je waardevolle spullen ter bewaring legt?

Ik denk dat de AVG hier al een prima antwoord op is. Bedrijven moeten vooral goed nadenken wat ze willen vragen en bewaren, of dat wel nodig is en voor hoe lang. Als ze dan die gegevens echt nodig hebben voor hun bedrijfsvoering moeten ze zelf zorgen dat dit goed beveiligd is. Het enige waar de overheid dus wel écht meer geld in moet steken is de Autoriteit Persoonsgegevens om hier op te kunnen toezien.

[Josk79]

Klinkt hartstikke leuk, maar zulke tools bestaan al in de vorm van diverse CMS-en en Frameworks die vele malen veiliger zijn dan de meeste WordPress installaties. Echter (1) gebruikt lang niet iedereen die en (2) biedt het geen garantie. Er is bijna altijd maatwerk nodig wat zomaar weer een kwetsbaarheid kan introduceren.

[Gijs007]

Onze fileprobleem krijgen we toch niet opgelost, het is al lang en breed uitgerekend dat het niet haalbaar is. Maar daar wil ik nu geen discussie over hebben.

Het file probleem is wel op te lossen. De overheid heeft in de afgelopen decennia echter te weinig rekening gehouden met jongere generaties die ook een auto willen en de toename in welvaart waardoor veel gezinnen tegenwoordig meer dan een auto hebben. De infrastructuur was en is daar niet op berekend.

Echter, net zoals de bevolkingsgroei op een gegeven moment stabiliseert zal dit ook met het aantal auto's gebeuren. We zitten nu immers in een fase waarin vrijwel alle leeftijd categorieën een auto bezitten.
Ook het vrachtverkeer is in de afgelopen jaren toegenomen door het gemak van internet en thuisbezorgen, maar ook dit zal op een gegeven moment stabiliseren.

Wellicht dat er weer andere trends zijn waar we nu nog niet aan denken die ook weer voor extra (vracht)verkeer zorgen. Indien dat niet het geval is dan zal de hoeveelheid verkeer en de benodigde capaciteit stabiliseren, waardoor we het file probleem wel degelijk op kunnen lossen door genoeg capaciteit te creëren in het wegennet.

[CAPSLOCK2000]

Ik wil hier eigenlijk niet over in discussie gaan, maar er is een relatie tussen hoeveel files er zijn en hoeveel auto's er op de weg zijn. Als er ergens meer asfalt komt dan nemen meer mensen de auto en verandert er netto weinig aan het fileprobleem. Als het op een stukje weg lukt om de files op de lossen, dan gaat het prompt fout bij het volgende verkeersknooppunt. Op een aantal plekken in Nederland is er gewoon geen plek meer voor nog meer asfalt zonder hele woonwijken af te breken of het groene hart op te heffen. Al zouden we het hele gebied tussen Rotterdam en Zwolle asfalteren dan zou het probleem nog niet zijn opgelost.
We zijn al tientallen jaren bezig met de wegen te verbreden en het heeft allemaal weinig zin, de drukte groeit sneller dan we kunnen asfalteren. Het is een wedstrijd die we nooit gaan winnen. Files oplossen doe je door te zorgen dat er minder voertuigen komen, niet met meer asfalt. De enige jaren dat de filedruk daalt zijn de jaren dat er een economische crisis is.

[hackerhater]

Zelfrijdende auto's zou een flinke reductie moeten geven omdat ineens de file effecten van de idioten op de weg (bumperkleven, afsnijden, etc) weg zijn.

[Twanekel]

Onze fileprobleem krijgen we toch niet opgelost, het is al lang en breed uitgerekend dat het niet haalbaar is. Maar daar wil ik nu geen discussie over hebben

Tuurlijk krijg je die wel opgelost, kost alleen wat meer dan miljarden... Biljoenen misschien

[Liberteque]

Ik ben echt al 7 jaar geleden begonnen al mijn (MKB) klanten terug te promoveren naar HTML. Fantastische beslissing gebleken. Weg met Joomla WP en al die andere ellende.. En nee de klanten kunnen geen artikelen meer plaatsen of informatie aanpassen. Dat doe ik gewoon weer, net als vroegah..

[WhiteDog]

Dat werkt waarschijnlijk wel voor de loodgieter of elektricien, maar bij de bakker en de slager hier kan ik toch echt wel online bestellen rond de feestdagen en daar zijn ze zelf ook wel blij mee

Ik vermoed dat sommige van je klanten dan ook niet alles uit hun zaak halen. Je klantgegevens online staan hebben betekent ook dat je er zelf overal aankan en dus sneller kan inspelen op offertes en tussendoor wat ander werk kan doen. Terwijl een technieker hier even zat te wachten (reparatie gelukt of niet) was hij gewoon online zijn factuur van zijn vorige klant aan het opmaken. Een kwartier dat hij mij kon aanrekenen en 's avonds laat gewonnen heeft...

[eborn]

Als je klanten dat accepteren en ook de onderhoudskosten accepteren die dit soort wijzigingen bij jou dan tot gevolg hebben, dan is dat natuurlijk een prima oplossing.

[cricque]

De meeste klanten bellen toch voor een update, en zelf iets aanpassen ... daar hebben de meeste geen kaas van gegeten, dus moet je het toch zelf doen. De meesten willen trouwens wel zelf alles kunnen aanpassen ... maar ze doen het ook nooit. Wordpress en consoorten zou gewoon moeten verbannen worden !

[Liberteque]

Ach de kosten zijn ongeveer hetzelfde gebleven en ze hoeven geen personeelslid meer te trainen en in te zetten om de website bij te houden. Ook zijn al die CMSsen zo lek als een mandje en staan ook overal en nergens geïnstalleerd en niet alle hosters hebben de beveiliging altijd even goed op orde.

Kijk er valt gewoon weinig te hacken ook nu met alleen maar HTML en een defacing heb ik nog nooit aan den lijve ondervonden en dat is sowieso snel verholpen..

Een echte grote HTML website is ook zo weer geüpload ipv die 30 miljoen bestandjes in duizenden mappen.. Ik onderhoud nog een paar webshops en een datingsite en that's all anno 2018..

[hackerhater]

Als ze inderdaad zelden iets aanpassen is een statische website veel beter.
Ik vraag klanten ook altijd hoe vaak de boel gewijzigd gaat worden en indien weinig raad ik ze een CMS af.

[Liberteque]

Een behoorlijk aantal klanten ik denk zeker 60% heeft regelmatig tot vaak wijzigingen. Het zijn dan vaak gallery's die geupdate moeten worden, of nieuwe werkzaamheden die het bedrijf is gaan ondernemen, tot aan een simpel telnummer dat is veranderd. Ik doe dat allemaal voor ze en dat levert mij ook geen windeieren op eerlijk gezegd en het levert mij ook nog een veel betere relatie op met deze bedrijven, want je moet echt met ze gaan samenwerken en dat is goed voor de lijm tussen klant en ICTer

[Verwijderd]

Ik denk dat je met Java en C# / ASP.NET een prima veilig CMS kan maken, dus ik deel je mening niet.

WordPress en Joomla zijn echter zo wijdverspreid dat het moeilijk is om iets anders te vinden bij een hosting bedrijf, tenzij je het zelf kan installeren.

[Reactie gewijzigd door Verwijderd op 23 juli 2024 03:06]

[Liberteque]

"Ik denk dat je met Java en C# / ASP.NET een prima veilig CMS kan maken, dus ik deel je mening niet."

Je deelt mijn mening wel want dat vind ik ook! Alleen voor de scope van mijn klanten is die constructie gewoon onnodig. Een installatiebedrijf of een schilder heeft gewoon geen CMS nodig (binnen het MKB)

[Verwijderd]

Ok, als ze verder geen content hebben die regelmatig gewijzigd moet worden, dan deel ik inderdaad je mening en kan je beter met HTML werken.

[Liberteque]

Haha dan deel je mijn mening met deze dan weer niet want zoals ik al schreef naar hackerhater even verderop:

"Een behoorlijk aantal klanten ik denk zeker 60% heeft regelmatig tot vaak wijzigingen. Het zijn dan vaak gallery's die geupdate moeten worden, of nieuwe werkzaamheden die het bedrijf is gaan ondernemen, tot aan een simpel telnummer dat is veranderd. Ik doe dat allemaal voor ze en dat levert mij ook geen windeieren op eerlijk gezegd en het levert mij ook nog een veel betere relatie op met deze bedrijven, want je moet echt met ze gaan samenwerken en dat is goed voor de lijm tussen klant en ICTer "

Het is een keuze die ik heb gemaakt waarvan ik wist wat me te wachten stond want vroeger ging het altijd zo voor al die DB driven websites. Ik wil niet meer terug (CMS), maar respecteer ook mijn collega's die CMSsen willen blijven gebruiken.. Each his own I guess

[hakog2]

Heb toevallig vorige week een soort van proxy gemaakt die html files die door WP worden gegenereerd naar disk schrijft. Vervolgens serveert een Apache vanaf disk alleen statische files. De WP installatie is niet vanaf buiten te benaderen. Als klanten een wijziging willen dan doe ik dat in WP. Mijn proxy ziet de wijziging en past de html aan. Alle gemakken van WP zonder de security issues.

[zynex]

Hier ben ik eigenlijk wel in geïnteresseerd, maar hoe gaat dat in zijn werk met niet static content zoals comments en contactformulieren? Voor comments kun je natuurlijk iets als Disqus gebruiken en ervan uitgaan dat zij de beveiliging op orde hebben, maar hoe zit dat dan met de meest gebruikelijke contact formulieren die tegenwoordig vaak de mogelijkheid moeten hebben om een bijlage toe te voegen? Dan moet je nog steeds een stukje php op je server draaien en daar zit dan direct weer een risico aan vast dat je in de gaten moet houden.

Dat is mijn inziens het probleem met Wordpress en andere cms systemen. Het werkt erg goed, maar juist doordat het veel te uitgebreid is, zijn er veel exploit mogelijkheden die constant onderzocht moeten worden. Daarom moet je Wordpress dus ook steeds updaten, maar tegelijkertijd moet je er dan ook vanuit gaan dat iedere plugin die je gebruikt dat ook doet. Weer iets om in de gaten te houden dus. Veel mensen updaten wel, maar hebben niet door dat de developer van een bepaalde plugin er allang mee gestopt is. Het is dus allemaal veel te complex voor de gemiddelde mkb'er. Vaak is er ook geen geld om constant aan beveiliging te werken en de eerlijkheid bied mij te zeggen dat tegenwoordig veel web developer/designer ook niet genoeg verstand van beveiliging hebben. Ik zelf doe ook maar hobbymatig wat af en toe, maar heb ook wel vaker contact gehad met 'professionele' webdesigners, maar ook zij zijn voornamelijk bezig met design en hebben vaak niet de kennis in pacht om voor goede beveiliging te zorgen en gebruiken dus ook standaard CMS systemen. (Althans voor de mkb'ers)

En om nou te zeggen dat websites enkel gemaakt mogen worden door security experts gaat mij ook nogal ver. Dan prijs je een hele grote groep mensen uit de markt. Wordpress is ook zo groot geworden dat het blijkbaar erg lonend is geworden voor hackers om exploits te vinden.

[Reactie gewijzigd door zynex op 23 juli 2024 03:06]

[Liberteque]

Ik gebruikte wel eens Jotform om contactforms te maken. Toen kon je die heel goed verbergen dat het van Jotform afkomstig was. Leek 100% native

[cricque]

Als ik nog eens de moeite doe om een website te bouwen voor een klant, dan zal het nooit WP/Joomla what so ever zijn, dit is gewoon vragen voor problemen, dus hier ben ik het helemaal mee eens

[BLACKfm]

En dan nog maar niet te spreken over WP/joomla achtige sites die gewoon het standaard pakket draaien, 95% van de opties niet gebruiken en dan lopen klagen als het contactformulier er 10 seconden over doet om geladen te worden op een Strato shared hosting.

Een eigen CMS (voor die enkele keer dat er dan wel een pagina bewerkt moet worden) is beheersbaar, je weet tenminste welke code je gebruikt en hoe dat aan te passen is.
HTML zou mij net weer iets te basic zijn, maar zoals hier al eerder is aangegeven, als de klant wil betalen voor je diensten en het bijhouden van de site moet dat geen probleem zijn.

[Takezo]

In het artikel in de Volkskrant staat:

“Een kanttekening is hier op zijn plaats: open poorten betekenen niet dat gegevens op straat liggen. Het ziektebeeld is geen open wond, maar een sluimerend virus. Met een dichte poort kan een hacker niets, maar een open poort biedt de mogelijkheid om een gebruikersnaam en wachtwoord in te voeren. Simpel gezegd: een open poort is als een deur die een inbreker kan proberen te forceren.”

Met vervolgens tekst dat er met brute force een miljoen wachtwoorden per dag kunnen worden geprobeerd.

Dit begrijp ik niet. Met een open poort heb je toch nog geen toegang tot een inlogscherm? Of wordt gedoeld op specifieke poorten voor SSH of FTP toegang? Maar die poorten moeten toch openstaan voor externe toegang door de site eigenaar?

[slaapkopje]

Het eerste wat je doet als hacker of bij een beveiligings audit is kijken welke poorten open staan vanaf het internet. Alleen een TCP verbinding is niet genoeg om binnen te komen, maar het biedt wel een mogelijkheid die je beter gewoon kunt afsluiten. Door poorten af te sluiten maak je de attack surface gewoon klein. FTP is onversleuteld, dus ook je wachtwoord wordt leesbaar verstuurd. SFTP als subsysteem van SSH is dan veel veiliger.

Voor SSH gebruik ik firewall rules en SSH keys zodat je niet vanaf elk netwerk kunt inloggen en niet een wachtwoord kunt bruteforcen (fail2ban en ipdeny kunnen daarbij helpen). Dat gecombineerd met consistent software patchen houdt de deur potdicht. En dan nog zijn er vendor problemen waardoor er toch nog een kiertje openstaat, dus ook goed monitoren wat er in je netwerk gebeurt.

[DJMaze]

Niet moeten, maar 'kan'.
Je kan namelijk ook een 2e server hebben met VPN/SSH om zo server 1 te beheren, dan hoeft de poort niet extern open te staan.

Zelf gebruik ik ssh sleutels, wachtwoorden werken niet.
En mijn database poort staat dicht. Kan je alleen bij via ssh tunnel.

[Reactie gewijzigd door DJMaze op 23 juli 2024 03:06]

[Verwijderd]

Met vervolgens tekst dat er met brute force een miljoen wachtwoorden per dag kunnen worden geprobeerd.

Dat is waarom ik op mijn server voor alle services die met internet in verbinding staan een fail2ban jail actief heb. Na 3 pogingen wordt het IP adres waarvan de gefaalde pogingen komen voor 24u geblokkeerd op de firewall.

[Verwijderd]

Duidelijk geschreven door iemand die er geen verstand van heeft. Achter de meeste open poorten zit niets, dus er valt ook niet op in te breken.

Maar het komt sporadisch wel eens voor dat iemand een database poort extern openzet. Dan nog moeten ze het admin wachtwoord zien te raden, en ik neem aan dat dit niet zo eenvoudig zal zijn.

[WhatsappHack]

Aan de andere kant heb je ook idioten die bijvoorbeeld de memcached poort publiek open hebben staan.

[PearZeaL]

De meeste mkb bedrijven hebben een website met wat informatie en een contactpagina. Nergens slaan ze persoonsgegevens op laat staan een database.

Als ik kijk naar de website van mijn vader, een meubelzaak dan stelt het helemaal niks voor en hij heeft natuurlijk geen database met klantgegevens.

Beetje rammelend artikel imo

[Groax]

Dat toevallig jouw vader geen DB heeft zegt niet dat andere website zoals die van je vader dit ook niet hebben. Hoe vaak wordt er een contact formulier opgeslagen in de DB en ook verstuurd via de mail? dit gebeurt meer dan je denkt. Restaurants slaan je boeking ook vaak op om hiermee statistieken te bouwen en misschien acties te versturen.

[BramV]

Dan is nog steeds niet nodig om de website direct aan een database te koppelen.

[cavey]

Zo ongeveer elke website waar een CMS achter hangt, heeft een database.

Worpress? Database
Drupal? Database
Joomla? Database

Dus overal worden gegevens verwerkt, opgeslagen (piwik/matomo/google-analytics/nedstat (leeft dat nog? )), statistieken gegenereerd. Logfiles. Als je er dan met slechte beveiliging (SSL2/3, TLS etc, heartbleed bugs en whatnot) langs kan komen om encrypted data te ontfutselen, slecht geupdate php baksels met XSS/SQL injects en andere bugs. Dan kom je zo in braakliggende databases terecht.

Vaak draaien de databases nog op dezelfde server, dus als je server door een nginx of apache hack ofzo binnengedrongen kan worden, kan je zo bij de mysql/postgresql database met alle gevoelige gegevens (email, naam, telefoonnummer komende uit een contact formulier, hele order systemen zitten er vast ook direct achter)

Dus om dan maar te zeggen "het is niet nodig om een website direct aan een DB te koppelen", neen, dat gaat niet echt op voor alle webshops en bedrijven waar je kan reserveren, contacteren, afspraken maken etc via het web.

[eborn]

Het argument: "databases draaien vaak op dezelfde server" zegt natuurlijk weinig, aangezien een webomgeving (bijna) altijd een directe koppeling met de database nodig heeft. Dus die inloggegevens zwerven altijd ergens rond op de server. Als je op het niveau zit dat je dat soort bestanden kunt lezen, maakt het niet uit waar de fysieke database draait.

[WhatsappHack]

Dat is ook het probleem eigenlijk. Je database encrypten is super leuk enzo, maar als de server de sleutel heeft dan kan een inbreker daar dus ook bij en heeft die hele encryptie geen enkele zin. Dat is eigenlijk gewoon waanzin.

[BramV]

- tja als je een blog systeem laat uitgroeien tot een soort van applicatieserver zoals Wordpress dan krijg je dat soort problemen.
- Nginx hacks ken ik niet.
- omdat het kan, betekent nog niet dat het een goede oplossing is.
- dat je even reserveringen bewaart in de aan de website gekoppelde database betekent nog niet dat je dat jaren lang daar permanent moet bewaren. Of al je klant contacten, of email adressen.
Zeker nu met de AVG moet je sowieso gaan afvragen wat je gaat bewaren, hoelang en waar etc...

[DJMaze]

Ja, en? Sinds wanneer staat een database gelijk aan persoonsgegevens?
Kan net zo goed niks in die database staan.

[Verwijderd]

een contact formulier dat gebruikt wordt is al een vorm van persoongegevens verwerken. Of het wordt opgeslagen in een database of ergens in een log file of al dan niet beveiligd verzonden etc

[BLACKfm]

Toch knap, "maandelijks 3,2 miljoen websites analyseren'. Ik weet niet hoeveel mensen er bij dat bedrijf werken, maar als je elke site een beetje wil doorlichten ben je denk ik zo 15 minuten bezig. En wie gaat dat allemaal betalen?

Iemand een bron naar die onderzoeksresultaten hoe deze zijn verkregen? Daar is waarschijnlijk hooguit een scriptje voor druk geweest die op basis van wat basale eigenschappen uitspuugt "Deze zijn onveilig".

En dat bedrijf is met dit tempo ook met een paar maanden klaar, zoveel domeinnamen zullen er nou ook weer niet zijn...

[Heedless]

SIDN had in in 2016 over 5.6 miljoen geregistreerde Nederlandse (.nl) domeinnamen. Zelfs als dat verdriedubbeld zou zijn in de afgelopen twee jaar zitten ze dus na ongeveer een enkele werkweek zonder werk

Ik neem aan dat dit een marketingpraatje is van het bedrijf en dat ze wat scriptjes hebben draaien die automatisch portscans doen en versies van Wordpress e.d. checken.

[Reactie gewijzigd door Heedless op 22 juli 2024 20:15]

[Takezo]

Het is een geautomatiseerde indexer, zo staat in de volledige (betaalde) versie van het artikel in de Volkskrant:

“Dataprovider.com is een 'internetcrawler' die onder meer werkt voor het Centraal Bureau voor de Statistiek (CBS), Google en Paypal. Het bedrijf indexeert maandelijks meer dan 113 miljoen websites, waarvan 3,2 miljoen in Nederland, op 174 kenmerken: in welke taal is de site, is er commerciële activiteit, hoeveel bezoekers komen er? Maar ook: beschikt de site over privacygevoelige gegevens van mensen, welke 'poorten' (digitale toegangswegen tot gegevens) staan er open, is er een beveiligde verbinding, draait de server op verouderde, inbraakgevoelige software?”

[Jester-NL]

Dus... Ik heb dit artikel twee keer bekeken op zoek naar andere links dan naar het artikel bij de Volkskrant. Een artikel waar ook al geen ruk instaat (behalve wat herhaalde kreten die in het artikel hier herkauwt worden).
Toen ben ik nog even bij dataprovider.com wezen kijken. Ook geen linkje naar een onderzoek. Sowieso vindt ik weinig nuttige info over dit bedrijf op hun site. Ze hebben bijvoorbeeld niet eens een adres op hun site staan...

All in all vraag ik me ondertussen af wat er exact in het onderzoek staat. Nu zijn beide artikelen (hier en bij de Volkskrant) niet meer dan een beetje klankkast spelen voor een vaag clubje met een hond

[mocean]

Staat gewoon hier: https://www.dataprovider.com/contact/
KVK hebben ze ook gewoon hoor!

[DJMaze]

Hmmm bij de KvK staat ook Mycaloriecoach en Lipperhey.
Die kennende is het niks anders dan een data harker met false positives en negatives.
Lipperhey werkt namelijk ook voor geen meter.

Ik heb hier een "onderzoek" liggen van zo'n soort bedrijf waarbij een hele rits aan beveiligingsproblemen naar voren kwamen die onjuist waren.
Toen ik ze er op aansprak dat de software die ze gebruiken slecht is (en ik kon in de server logs zien welke), hadden ze geen antwoord

[Reactie gewijzigd door DJMaze op 23 juli 2024 03:06]

[eric.1]

en het al dan niet openstaan van poorten.

Ik vraag me eigenlijk wel af hoe relevant deze info is. Ik durf best een gokje te wagen dat deze "geweldige" websites 9/10 keer op een shared hosting omgeving staan...dan zit het probleem niet zozeer in de website van een MKB-er maar in het systeem waar deze op draait van de hoster.

Verder verbaasd het me werkelijk niets. De paar MKB-ers die wij als klanten hebben willen echt geen ene rode cent uitgeven aan "ICT"-zaken. Sjah, dan krijg je dit.

[Reactie gewijzigd door eric.1 op 23 juli 2024 03:06]

[Annihlator]

Ik vind niet dat de Telegraaf kan stellen dit te hebben onderzocht; uit de statistiek blijkt dat de partij die het heeft gepoogd te onderzoeken niet voldoende kennis heeft om dit te doen...

[Redwood]

Onlangs stond er bij RTV Noord een soortgelijk item. Een lokaal webdesign bedrijfje had alle 190 websites van alle amateurvoetbalclubs gescreend op veiligheid en slechts twee voldeden aan de eisen. De twee die “geheel toevallig” door datzelfde bureautje zijn gemaakt.

Dit komt dan naar buiten als “persbericht”...
Het Volkskrant “artikel” doet mij hier behoorlijk aan denken.

En zoals eerder gezegd werd, bedrijven willen er ook niets aan uitgeven.

Overigens is er helemaal niets mis met een goed onderhouden Wordpress sites. We hebben er heel veel draaien, zonder issues. Een brute force is een aantal jaren geleden nog wel eens voorgevallen, alleen sluiten we dat nu uit door de instellingen m.b.t. brute force en aantal foutieve login pogingen aan te passen.

Ooit nog eens een site gehad gehost voor een Elvis Fanclub waar hun admin login “Elvis” was en het wachtwoord “Presley”.
Er zijn nu alleen nog maar veilige wachtwoorden mogelijk!

Wij slaan online een hele boel gegevens op, al staat ons administratiepakket staat als enige op een separate server. De backend is dmv two-factor en allow from ip beveiligd. Hetzelfde geldt voor de folders.
In mijn optiek is online&100% veilig heel moeilijk te realiseren, maar het is gewoon dom om bewust “het hek open te laten staan”.