Datalek in Infectieradar maakte achterhalen van coronasymptomen mogelijk

De website waarop Nederlanders kunnen aangeven of ze coronasymptomen hebben bevatte een lek. Daarmee was het eenvoudig om de medische data van deelnemers op te vragen. Dat kon door simpelweg de url van de Infectieradar te veranderen, meldt een beveiligingsonderzoeker aan de NOS.

Het gaat om Infectieradar, een website van het Rijksinstituut voor Volksgezondheid en Milieu. Op de website kunnen Nederlanders symptomen rapporteren die met het coronavirus te maken hebben. Op die manier kan het RIVM de verspreiding van de ziekte in de gaten houden. Het datalek maakte het mogelijk die symptomen van gebruikers op te vragen.

Deelnemers van Infectieradar krijgen een uniek id toegewezen dat uit acht cijfers bestaat. Wie een vragenlijst op de site invult kreeg dat nummer in de url-balk te zien. Beveiligingsonderzoeker Tom Wolters ontdekte dat dat cijfer in de url simpel kon worden vervangen. Door dat te veranderen kreeg hij het formulier van andere deelnemers te zien.

Dat werkte ook geautomatiseerd. Wolters stapte met zijn bevindingen naar de NOS. Samen lukte het hen om binnen zo'n twee minuten de gegevens van 44 gebruikers te achterhalen. In totaal deed de NOS 128 verzoeken naar de servers achter de site.

Een aanvaller kan geen namen van deelnemers zien, maar wel e-mailadressen, geboortejaren en postcodecijfers. De acht cijfers van het id werden volgens de NOS gerangschikt op e-mailadres. Daardoor zou het ook eenvoudig zijn gericht te zoeken naar gebruikers.

Gebruikers van Infectieradar moeten zich eerst aanmelden met een account. Vervolgens geven ze medische en persoonlijke gegevens over zichzelf door, bijvoorbeeld of ze roken of zwanger zijn, allergieën hebben, en welke medicijnen ze gebruiken. Deelnemers krijgen daarna wekelijks een vragenlijst toegestuurd waarop ze aangeven of ze coronasymptomen hebben.

Infectieradar bestaat sinds 17 maart. Het lek zit al sinds die datum in de site. Wel zegt het RIVM tegen de NOS dat de nieuw ingevulde formulieren dagelijks geleegd worden.

Na melding van de NOS heeft het RIVM het formulierengedeelte offline gehaald. Het is nog wel mogelijk aan te melden met een account, maar niet meer om symptomen in te vullen. Het is overigens niet de eerste keer dat de site in opspraak komt. Een week na de introductie werd de site ook al offline gehaald toen bleek dat het systeem erachter, Influenzanet, oud en onveilig was.

De overheid werkt op dit moment ook aan verschillende manieren om apps en data in te zetten in de strijd tegen het coronavirus. De bekendste daarvan is een contact-tracing-app die op basis van bluetooth werkt. Op die app komt veel kritiek; veel experts zijn bang dat de overheid de app overhaast wil invoeren en dat er daardoor grote privacyrisico's aan de app kleven. Hoewel Infectieradar losstaat van de corona-app is het lek mogelijk erg schadelijk voor het vertrouwen van gebruikers.

Reacties (239)

[barefoot]

Mijn naam is Edo Plantinga en ik werk in opdracht van VWS aan de "contact-traceer app", die we overigens tegenwoordig de "covid-19 notificatie-app" noemen, omdat de app geen contacten traceert. Mijn rol is community manager.

In dit artikel wordt begrijpelijkerwijs de link gelegd tussen deze grove fout en de notificatie-app. Ik snap het helemaal en tegelijkertijd baal ik hier enorm van, omdat we met de notificatie-app echt privacy first werken en er goed naar security aspecten wordt gekeken. Een voorbeeld: we kijken naar decoys om ook op netwerk niveau niet afleidbaar te kunnen maken of iemand corona heeft.

Ik snap heel goed dat dit incident het vertrouwen in ict ontwikkeling in de overheid schaadt, en daarmee ook het vertrouwen in de ontwikkeling van de notificatie-app. Om dit vertrouwen hopelijk wat te helpen te herstellen, nodig ik geïnteresseerden uit om de broncode van de notificatie-app (in ontwikkeling) te bekijken via https://github.com/minvws/ (pull requests welkom) en mee te praten en mee te helpen via de Slack van stichting Code for NL via https://doemee.codefor.nl/ (kanalen beginnend met #notificatie-app). Ik geef vanuit mijn rol hier op Tweakers graag toelichting over hoe we open ontwikkelen. Meer technische vragen kun je stellen via de kanalen die ik net noemde.

[Reactie gewijzigd door barefoot op 23 juli 2024 15:56]

[TheAncientDovah]

Ik ben zojuist door de documentatie van de applicatie gegaan. Ik zie dat jullie een lijstje hebben met een aantal belangrijke vragen die gebruikers kunnen hebben. Hieronder staat ook: "waar wordt deze data opgeslagen?". Ik zou hier gerust van maken "Welke data wordt opgeslagen en waar?".

Schokkend vind ik echter dat ik hier geen antwoord op vind in de documentatie. Zeker gezien jullie aangeven te willen werken volgens de principes van 'privacy by design'.

Er zit een wezenlijk verschil tussen of je contactgegevens opslaat op een centrale server of bij iedere gebruiker individueel.

Kijk ik niet goed genoeg of hebben jullie hier inderdaad nog niet over nagedacht?


[UPDATE]

Lijst met gebruikersvragen: https://github.com/minvws...ster/vragen-gebruikers.md
Diagrammen die grotendeels aangeven wat ik zocht: https://github.com/minvws...olution%20Architecture.md

De vraag die mij nog rest na het zien van de laatste link is wat voor "Associated Encrypted Metadata" wordt verstuurd. De anonimiteit van de oplossing zal ook hier van af hangen.
Het is nogal een specifieke vraag, maar ik verwacht het te zijner tijd wel in het privacy statement terug te kunnen lezen. Ik kan me ook voorstellen dat het in deze fase wellicht nog onduidelijk is.

Over het algemeen vind ik het ontwerp best goed in elkaar steken!

[Reactie gewijzigd door TheAncientDovah op 23 juli 2024 15:56]

[barefoot]

Terechte vragen die je hebt. Er is wel degelijk over nagedacht gelukkig. Kort gezegd hanteren we de 10 principes van https://www.veiligtegencorona.nl/ als uitgangspunt (disclosure: ik ben een van de initiatiefnemers hiervan). We werken op basis van de Google Apple Exposure Notification API. Dat betekent dat de data anoniem en lokaal op je telefoon wordt opgeslagen.

De communicatie naar het grotere publiek loopt helaas nog wat achter bij waar we staan. Een community van vrijwilligers (hulde!) werkt samen aan een projectstatus website, zie de prototypes hier: https://www.figma.com/fil...ificatieapp?node-id=0%3A1. Hulp is welkom via https://doemee.codefor.nl, kanaal #notificatie-app-status-dashboard.

[mbbs1024]

Is het werken met software van bekende dataslurpers op zich al geen verkeerd uitgangspunt ?
Wie vertrouwt er gevoelige gegevens, zoals medische data nu toe aan een Amerikaanse data verzamelaar, die bovendien verplicht is om dat aan de Amerikaanse overheid door te geven indien die daar in geinteresseerd zijn.

[gday]

Kun je wellicht iets specifieker zijn over welke lijst je het precies hebt en waar die staat? De code, documentatie en ontwerp van de app zijn verdeeld over meerdere repo's.

Praat gerust mee op Slack of dien je input in als issue in een van de relevante Github-repo's. (Dat is uiteindelijk ook wat Edo hierboven aangaf.)

[gday]

Wat betreft je update:
De Associated Encrypted Metadata bestaat uit twee delen die alleen van belang zijn op het moment dat iemand positief test. Dat zijn de versie van het protocol en de sterkte van het Bluetooth-signaal ten tijde van een ontmoeting. Dat laatste kan worden gebruikt voor afstandsbepaling tot andere devices waar een match mee is gevonden om zo iets meer te kunnen zeggen over het besmettingsrisico. Dit is niet zelfverzonnen maar is gedefinieerd in het protocol dat Apple en Google samen ontwikkeld hebben. Zie ook de definitie in https://covid19-static.cd...oothSpecificationv1.2.pdf

[Reactie gewijzigd door gday op 23 juli 2024 15:56]

[Mellow Jack]

Het is niet zozeer een grove fout maar naar mijn mening meer een fundamenteel verkeerd uitgangspunt bij het ontwerpen van zo'n app.

Als je het fundament niet goed hebt als je wel security puntje fixen maar blijft het dweilen met de kraan open.

Maar iig, leuke rol en succes

[TheAncientDovah]

Maar alle geintereseerde je broncode laten zien klinkt ook niet heel verstandig en veilig.

Het publiceren van broncode stelt anderen in staat te verifieren dat een systeem veilig is. Het klopt echter ook dat dit het makkelijker maakt voor kwaadwillenden om diezelfde kwetsbaarheden te vinden.
Als een kwaadwillend persoon echter op zoek is naar een kwetsbaarheid vind hij er uiteindelijk toch wel een.

Over het algemeen kan je stellen dat de veiligheid van een systeem niet afhankelijk moet zijn van de geheimheid van het ontwerp, maar van de geheimheid van de sleutels.

Wellicht een interessante bron die dit beter verwoord dan ik: https://blog.cloudflare.c...out-kerckhoffs-principle/

[Mellow Jack]

Meest cruciale stukjes qua beveiliging zullen hopelijk niet in de code zitten. Denk aan de identity store (gebruikers), identity provider (partij die authenticatie verzorgd) maar ook zaken als certificaten, wachtwoorden en tokens.

Het enige wat je aan de code zou moeten kunnen zien is of ze zich aan de standaarden houden.

Websites en verkapte websites zoals dit soort apps gebruiken vaak bijvoorbeeld oAuth2.0

Natuurlijk, als ze fouten maken dan kan je dat zien maar als ze fatsoenlijk coden dan wordt iets niet onveilig door het publiceren van je code

[Anoniem: 718943]

Als je ontwerp in de basis goed zit, dan kun je gewoon de broncode laten zien. Als je beveiliging afhankelijk moet zijn van het niet inzichtelijk zijn van de code, dan is dat al een hele grote indicatie dat er iets mis is.

En als je je code niet wilt laten zien omdat je bang bent dat er misschien een fout in je beveiliging gevonden kan worden, dan is dat gelijk ook het niveau van vertrouwen dat je hebt in je ontwerp en het opgeleverde product.

Natuurlijk snap ik wel dat je je code gesloten wilt houden voor bescherming van IP, dat heeft dan gelukkig ook niets met security te maken.

[Manke]

Hoeveel betaalt VWS eigenlijk voor zo'n project?

[_rimo]

Wel jammer dat je aan een vrij nutteloze app werkt. Ook in deze app is alles gebaseerd op de aanname dat infecties rond ongeveer 1,5m plaatsvinden, terwijl het allang duidelijk is dat 1 persoon tientallen tot honderden tegelijk ver buiten 1,5m kan aansteken in specifieke binnenomgevingen.

Dan heb je niet zoveel aan zo'n app dus. Waarom zouden mensen ook maar enig risico op privacy-verlies willen lopen als het toch gedoemd is om te falen? Ik had het geïnstalleerd als ik echt had geloofd dat het werkte, maar nu pas ik er voor.

[Reactie gewijzigd door _rimo op 23 juli 2024 15:56]

[jotheman]

Mag ik je even complimenteren op het feit dat je zelf in alle openheid reageert op dit bericht en deze informatie deelt. Los van de app, het project en wat dan ook, getuigt dat voor jou als persoon van karakter en openheid.
De kritische commentaren en opbouwende feedback laat ik aan de overige Tweakers over, maar ik wilde dit even vermelden

[barefoot]

Dank je wel, wordt gewaardeerd. Dat is hoe we met dit project willen werken: van een constructieve dialoog kan het alleen maar beter worden. Wat we doen is best bijzonder vind ik zelf, bijvoorbeeld: via de Slack groep van Code for NL waar we te gast zijn (zie https://doemee.codefor.nl/) treedt de opdrachtgever Ron Roozendaal (CIO van VWS, ook voorstander van privacy) direct in gesprek met mensen van Bits of Freedom. Ik vind dat fascinerend om te zien en heb daar veel bewondering voor, zowel voor Ron als Bits of Freedom.

[azortje]

Edo zijn punt is dat hij werkt aan een andere app, niet de website.

Hij geeft aan dat hij het jammer vindt dat dit nieuws waarschijnlijk ook slecht afstraalt op de notificatie/contact tracing app. Om dat kracht bij te zetten geeft hij aan dat zij echt privacy first werken, wat hij verder ondersteund door te zeggen dat de code vrij inzichtelijk is, en dat ze zelfs openstaan voor pull requests om te laten zien dat zij begrijpen dat anderen mogelijk waardevolle aanvullingen hebben.

Edit: slecht lopende zin herschreven.

[Reactie gewijzigd door azortje op 23 juli 2024 15:56]

[vivoergocogito]

Ook al werkt hij aan een andere app dan nog blijft mijn punt overeind, de stroom ict "incidenten" gaat niet stoppen na deze post van Edo, en ook al werkt edo wel open en transparant, het is geen garantie dat dat zo is bij een willekeurig ander overheids ict project. Dus Edo vraagt om vertrouwen want dat is gedaald door een "incident" bij de overheid. Ik vind die vraag onterecht want het betreft geen incident.
Persoonlijk ben ik van mening dat ALLE overheids ict projecten opensource dienen te zijn en dat ook zelfs databases (geanonimiseerd) voor ALLE Nederlanders toegankelijk zijn evenals door de overheid gesubsidieerd wetenschappelijke onderzoeken.
Om echte vooruitgang te boeken is openheid van data nodig, fijn dat Edo dit nu doet, maar dit is geen regel bij de overheid. En dus vind ik zijn oproep misplaatst want Edo weet ook dat het probleem niet ligt in de ict-er maar bij de organisatie die de ict-er aanstuurt. Wanneer we de organisatorische kant transparant maken dan maken we ook macht transparant en bepaalde soorten macht laten zich niet graag transparant maken.

[barefoot]

Dank voor je reactie @vivoergocogito. Ik ben met je eens dat meer overheidsprojecten open source moeten zijn, zie (bijvoorbeeld) dit artikel waaraan ik meeschreef https://ibestuur.nl/nieuws/winst-op-tien-punten. Open source zonder het stimuleren van bijdragen zie ik als minder effectief.

Waarom ik dan zelf niet gratis werk? Ik snap en waardeer dat je die vraag open stelt, dat geeft me de gelegenheid te reageren 🙂. Ik werk zelf meer dan full-time op dit project en gotta pay the bills. Daarvoor heb ik 4 weken al mijn tijd naast homeschooling vrijwillig aan corona projecten besteed overigens, dus ik vraag niet van anderen wat ik zelf niet ook gedaan heb. 🙂.
Hoop dat dit wat van je vragen beantwoordt.

[daredevil__2000]

Je snapt wel dat je nu iemand die verantwoordelijk is voor 1 specifiek project verantwoording af probeert te laten leggen voor ALLE overheidsprojecten. Projecten waar deze persoon niets mee van doen heeft gehad?

Dat is hetzelfde als de IT-ers van de universiteit utrecht verantwoording af proberen te laten leggen over het blunderen van de IT-ers van de universiteit maastricht waardoor ze getroffen werden door ransomware.

Spreek de mensen er op aan die er daadwerkelijk wat aan kunnen doen en niet iemand die het nu wel eens goed probeert te doen met een overheidsproject.

[vivoergocogito]

Jij snapt ook wel dat ik hem die verantwoordelijkheid niet in de schoenen probeer te schuiven dan wel zijn in onze gedeelde optiek positieve project probeer te laten mislukken. Nee ik voerde een discussie met een persoon die zich voorstelt als community manager van een corona app van de overheid bij het ministerie van VWS waarin we het hebben over opensource projecten in relatie tot de overheid en de relatie met gratis hulp van burgers.

Op zijn linkedin pagina staat anders wel : Projectleider, product owner en adviseur met ruime ervaring in de online overheid. Ik werk aan projecten met maatschappelijke impact, waarbij ik anderen weet te enthousiasmeren, te overtuigen en te verbinden.
OK dus iemand die werkt bij vws aan een corona app heeft geen weet van een andere corona project dat wordt geleid door datzelfde ministerie, dan is dat waar de discussie over zou moeten verder gaan denk ik.
Tweede edit : ik begrijp nu pas dat die meneer niet in vaste dienst is bij vws, nu begrijp ik ook uw verbolgenheid over mijn commentaar maar ik heb het nooit persoonlijk of gemeen bedoelt maar ging er vanuit dat deze meneer projectleider was in vaste dienst van vws en daarom vond ik het vreemd dat hij die stelling aanging. Ik was graag een echte discussie over het onderwerp aangegaan en die kwam helaas niet van de grond door mijn foute aanname.

[Reactie gewijzigd door vivoergocogito op 23 juli 2024 15:56]

[barefoot]

Sinds mijn studie kunstmatige intelligentie en mijn jammerlijk mislukte poging 15 jaar geleden om via recursieve multithreaded reguliere expressies in Prolog Doom te emuleren op een laserpointer, zijn mijn programmeerskills inderdaad ernstig in het slop geraakt, mea culpa 😉. Fijn weekend verder!

[barefoot]

De vraag is denk ik of je voorstander bent van het model van de participatiesamenleving, waarbij je burgers vraagt mee te helpen met maatschappelijke uitdagingen, of dat je liever meer belasting betaalt en dan de overheid meer mensen laat betalen om de maatschappelijke uitdagingen te lijf te gaan. Ikzelf ben voorstander van het eerste model, maar ik zie ook de voordelen van het andere model wel. En ik snap ook uw irritatie over het eerste model wel denk ik.

[dasiro]

Zijn er in al die jaren al niet genoeg voorbeelden geweest van hoe fout het met dit soort sites kan lopen? Dat je 20 jaar geleden zoiets kon doen was al erg, maar dat je nu nog steeds idioten hebt die zo'n implementatie afleveren is gewoon schandalig en daarvoor mogen ze gerust aan de publieke schandpaal genageld worden.

[Nas T]

Ik wil niemand aan de schandpaal nagelen. Al die jaren dat we het nu fout hebben zien gaan, zonder dat daar structureel iets in gewijzigd is. Ik denk dat we hele andere maatregelen nodig hebben, zoals een nul data beleid.
Ik kan drie redenen geven waarom je alles te verbergen hebt:
1. Overheden willen alles weten: kijk wat naar Snowden jaren geleden heeft laten publiceren, kijk naar het gedoe om de sleepwet (WiV) en naar hoe vaak de overheid de regels niet volgt.
2. Incompetentie: dit, plus vele, vele andere voorbeelden zijn er te vinden waarin een overheid data zeer slecht verwerkt.
3. Onethische intenties: kijk naar SyRI. Op het moment dat onschuldige burgers gekenmerkt worden als potentieel fraudeur, stopt de overheid zelf niet, maar moet een rechter het project laten stoppen.

Ik denk dat er weinig mensen met droge ogen kunnen zeggen dat de overheid (in zijn algemeen) nog enigszins geloofwaardig is in het verwerken van gegevens.
Nu is de bestrijding van COVID19 een sterk argument, evenals terrorisme, evenals pedofilie. Maar let op waar de grens is dat het een pressiemiddel is of een valide argument. Ik heb geen probleem om data te delen met wie dan ook, zodra het in het algemeen belang is. Maar: het moet nut hebben. Zodra je als bedrijf of overheid gegevens wilt verzamelen, dan moet dat in ons belang zijn. Ik zie niet in wat mijn emailadres bijdraagt in het bestrijden van COVID19, dus wat mij betreft krijg je die niet (of het moet heel duidelijk zijn dat dit van toegevoegde waarde is). Bij bedrijven is het prima dat mijn data gebruikt wordt om een dienst of product mee te bekostigen, maar geen winst. Nog sterker: winst is een prikkel om nog meer data te verzamelen, wat in het nadeel is van de consument. Dat moeten we dus niet willen.

Dus heel simpel: Geen nut? Geen data. Draagt data bij aan winst? Geen data. Ik hoop echt dat we een keer een politieke partij krijgen die zich hierom druk maakt, en niet meer om de etnische samenstelling van de mensen die ik in de supermarkt zie. Want ik heb niet het besef dat dat de afgelopen 20 jaar is veranderd. Maar ik besef elke maand meer hoe belangrijk onze gegevens zijn en hoe ver het is gekomen.

[eekhoorn13]

Doet mij denken aan deze blog van signal. Waarin ze uitleggen dat ze inderdaad zo'n nul data beleid hebben: https://signal.org/blog/l...-the-world-moves-forward/

"Grappig" dat jij dit nu ook ter sprake brengt. Ik had er nooit zo over nagedacht en heb uit mezelf ook de "als je het maar goed beveiligd" benadering. Maar de kans is inderdaad groot dat ergens toch een steek laat vallen. Data gewoon niet hebben is natuurlijk de beste beveiliging tegen data lekken.

[Kastermaster]

Heel kort en lullig antwoord op je post waar ik het overigens volledig mee eens ben, maar we hadden toch zo'n partij? De Piratenpartij. Die haalden alleen de kiesdrempel niet. Kan me nog herinneren dat ik (gebrek aan) privacy het grootste probleem van de 21e eeuw vond toen ik op ze stemde. Om vervolgens zelf hypocriet op Facebook aan te kondigen dat meer mensen dat zouden moeten doen😅

[GenGF]

De overheid, IT en haastwerk. Een ongelukkige combinatie. Dat is nooit veranderd.

[KoffieAnanas]

Maak er IT en haastwerk van. Dit staat los van de overheid. Legio voorbeelden uit het bedrijfsleven.

En wat denk je van Zoom, en zijn we Facebook alweer vergeten? Beide niet eens haastwerk, maar nonchalance.

Altijd makkelijk om een polulair statement te maken, IT en overheid gaan niet samen. Maar we horen nooit wat van de goede voorbeelden van overheid en IT. En van de overheid slikken we minder goed fouten. Van het bedrijfsleven vinden we het allemaal wel best.

[GenGF]

Het aanzienlijke verschil is dat je tussen bedrijven nog concurrentie hebt en dus voor een andere partij kan kiezen als er een tussen zit die het verknald. Die luxe heb je niet bij de overheid, dus ja, daar verwachten wij meer van. De problemen daar zijn structureel. Dat is niet een makkelijk, populair statement maar de harde werkelijkheid. De overheid (ministers, RIVM) wil graag dat we massaal onze informatie inleveren, maar ze kunnen er nog steeds niet mee overweg. Iets waar onder andere op Tweakers al voor gewaarschuwd werd toen de plannen nog maar geruchten waren.

En dan is er de hypocrisie. Als de overheid van andere partijen verwacht dat de gegevensbeveiliging op orde is en er zelfs wetten van maakt, dan mag je er toch vanuit gaan dat ze daar zelf extra hard op inzetten? Het is net alsof de politie adviseert om stevige sloten te gebruiken en ze zelf de sleutel in het slot laten zitten. Iedere keer weer. Dit soort stunts wordt het vertrouwen in de overheid niet beter van.

Gelukkig zijn er ook projecten die wel goed gaan. We hebben namelijk een heleboel onderdelen binnen onze overheid en een deel daar van doet z'n werk wel. Helaas hebben die te lijden onder de beginners-acties van hun collega's. Gelukkig lijkt het team van de App zich hier beter bewust van. We gaan het zien. Vertrouwen komt te voet en gaat te paard.

[TheekAzzaBreek]

De overheid, IT en haastwerk. Een ongelukkige combinatie. Dat is nooit veranderd.

Flauw. Dit is door een commerciële partij gebouwd.
Ok, ze hadden er een betere audit op kunnen zetten, maar dit is het niveau dat ze geleverd krijgen.

[scsirob]

Die commerciële partij krijgt vaak onrealistische deadlines voorgeschoteld, moet via aanbestedingen de opdracht binnenhalen waarbij prijs het primaire selectiecriterium is. De overheid wil voor een dubbeltje op de eerste rang zitten, en dat wreekt zich.

Vaak moet er in korte tijd een proof of concept gebouwd worden, waar alleen functionaliteit getoond wordt. Door tijds- en financiële druk wordt dat stukje proof-of-concept code verheven tot de basis van de productiecode. Slechts zelden wordt van scratch een nieuw fundament opgezet waarin alles inherent veilig is. Security wordt dan een sluitpost in plaats van een uitgangspunt.

[TheekAzzaBreek]

Ik heb aan aardig wat overheids IT klussen meegewerkt, en zo gaat het inderdaad regelmatig (gelukkig niet altijd), maar het gaat me te ver om de verantwoordelijkheid daarvoor helemaal bij de overheid te leggen. De aanbieder heeft ook de verantwoordelijkheid om een bepaald kwaliteitsniveau te leveren.

Zoals ik het te vaak heb zien gebeuren:

Als er een aanbieding gedaan moet worden wordt er een teampje opgezet met een of twee ontwerpers en als je geluk hebt een materiedeskundige. Die maken een ontwerp waarna er een projectmanager bijgehaald wordt. Samen maken die naar eer en geweten een plan, met tijdlijn, mandagen en vereiste skill levels. Daar volgt dan een bedrag uit.

Vervolgens komt de accountmanager er bij, die zegt dat we voor dat bedrag de opdracht niet gaan binnenhalen, waarna het grote strepen begint. Dat begint in mijn ervaring steeds met skill levels, met wat juniors en en senior om ze te begeleiden moet het ook wel lukken. Vervolgens wordt er gesneden in de marges voor onvoorzien, voor tegenvallers kunnen we ze wel een RFC in de maag splitsen. Past het dan nog niet dan wordt er in de planning gesneden, wat door de voorgaande stappen heel hachelijk is geworden.

Ik vind dat je in zo'n situatie tegen de klant moet kunnen zeggen: we kunnen wel iets aanbieden voor dat bedrag, maar dat levert je deze risico's op in veiligheid, onderhoudbaarheid, opleverdatum of wat dan ook.
Of je zegt: voor dat bedrag kunnen we je niet leveren wat je vraagt met de kwaliteit die wij horen te bieden.

Als je als leverancier sub-standaard aanbiedt om aan onrealistische eisen van de klant te voldoen ben je minstens zo verantwoordelijk als die klant, Meer nog, want jij wordt verondersteld de professionele partij te zijn.

[kodak]

Was er hier sprake van een onrealistische deadline of was de software al heel oud en door een bedrijf aangeboden als makkelijke oplossing?

[Wasabi!]

Lijkt de Ziggo randapparatuur webshop wel.
Kon je gewoon je link doorsturen en ergens anders gewoon vooraf ingevuld verder gaan.

[NielsFL]

Zolang die URL een unieke en voldoende lange random string bevat hoeft dat geen probleem te zijn. Een gebruikersnaam+wachtwoord is immers ook niet meer dan dat.

Wat zo'n URL potentieel gevaarlijk maakt is dat de gebruiker mogelijk niet weet dat er een authenticatie sleutel in verwerkt zit en deze dus deelt.

Maar dat is wat anders dan eenvoudig oplopende nummers zoals het RIVM kennelijk lijkt te gebruiken.

[Wasabi!]

Zolang die URL een unieke en voldoende lange random string bevat hoeft dat geen probleem te zijn. Een gebruikersnaam+wachtwoord is immers ook niet meer dan dat.

Wat zo'n URL potentieel gevaarlijk maakt is dat de gebruiker mogelijk niet weet dat er een authenticatie sleutel in verwerkt zit en deze dus deelt.

Maar dat is wat anders dan eenvoudig oplopende nummers zoals het RIVM kennelijk lijkt te gebruiken.

Duidelijk, weet ook nog dat je flinke korting kreeg bij Dell, etc. door de landen code of wat anders te veranderen in de url, wat een tijd.

[Bensimpel]

Publieke schandpaal, maybe. Of zwaarder straffen van bedrijven die hier denken mee weg te komen. Misschien ook eens eindelijk de eindverantwoordelijke echt verantwoordelijk stellen. Dan wordt hier wel beter op gelet. Dat weet ik wel zeker. Ook het besef van de programmeur zelf mag eens verbeterd worden.

[snellie123]

Dat hier vroeg of laat een lek ontdekt zou worden was natuurlijk wel te voorspellen. Maar dat dit zo'n fundamentele grote fout betreft in het ontwerp van de site is schandalig. Dat het makkelijk op te lossen is is fijn maar had dat wat eerder gedaan, elke developer weet dat je die codes niet moet gebruiken in de adresbalk...

[Rannasha]

Dat het makkelijk op te lossen is is fijn maar had dat wat eerder gedaan, elke developer weet dat je die codes niet moet gebruiken in de adresbalk...

Het fundamentele probleem is niet eens de user-id in de adresbalk. Want stel dat je in plaats van een HTTP GET (met id in de adresbalk) een HTTP POST (met user-id niet direct zichtbaar / manipuleerbaar) verzoek zou doen om verbinding te maken, dan kan iedere gebruiker die handig genoeg is om de developer console te openen in een browser (dwz: iedereen die de F12 knop kan vinden op z'n toetsenbord) precies zien welk verzoek wordt gebruikt om de gegevens op te vragen en het manipuleren hiervan is vervolgens ook eenvoudig.

De kern van de zaak is dat men niet moet werken met enkel een user-id om bij de gegevens te komen, maar met de combinatie van een user-id en door de gebruiker gekozen wachtwoord (en idealiter nog 2FA). Zodra je een wachtwoord vereist, kun je direct niet meer bij andermans gegevens door simpelweg een ander user-id in te vullen.

[Kentsfield]

Eens, maar een guid was al een stuk beter geweest. Klinkt alsof er een auto increment primary key als link is misbruikt. Als dit zo is, dan is dit geen haast klus maar incompetentie.

[Mellow Jack]

Überhaupt zoiets sturen is niet zo fijn. Hou het bij een https request GetMyForm als je niet wilt dat iemand een account hoeft te maken stuur je ze een mailtje met een token die geldig is voor een x aantal minuten/uurtje

[fre0n]

ook post data is lek, met de dev tools (f12 in chrome) kun je die net zo gemakkelijk zien en manipuleren. Dit moet gewoon backend in een database oid worden afgehandeld en gevalideerd

[Reactie gewijzigd door fre0n op 23 juli 2024 15:56]

[Core2016]

De app is feitelijk een I/O device. Dit moet met de nieuwste en beste technieken gecontroleerd worden. Het moet bij gehouden worden. Een client is inderdaad niet te vertrouwen. Moet je na gaan wat je met de terminal kan. Dat ook nog eens automated.

[JosvnE]

Fundamentele grote fout is een understatement. Misschien dat een eerste-jaars student in een schoolopdracht zoiets zou maken, maar geen enkele IT professional. Als een IT bedrijf zoiets oplevert hebben ze kennelijk dit door een stagiaire laten maken, en geen begeleider heeft een software code review gedaan. De fundamentele fout is dat zo'n IT bedrijf kennelijk geen fatsoenlijke ontwikkelprocedure volgt. In zulke gevallen zou vaker geld terug geëist moeten worden, en het bedrijf uitgesloten van verdere opdrachten.

[bilbob]

idd, dit is geen fout meer te noemen.. dit is geen idee hebben waar je mee bezig bent..

[Rutix]

Als een IT bedrijf zoiets oplevert hebben ze kennelijk dit door een stagiaire laten maken, en geen begeleider heeft een software code review gedaan.

Ik denk echt dat je veel IT bedrijven overschat. Ik ken echt zoveel IT bedrijven waar fundamentele security kennis zoals dit er gewoon niet is (ook niet bij de seniors). In zulke bedrijven zitten wel vaak ontwikkelaars die goed zijn en het goed kunnen maar die werken meestal aan leuke of complexere projecten of projecten waar meer geld word opgehaald. De partijen waar de overheid vaak mee werkt hebben beheer teams die dit doen en waar een dubbeltje voor gevraagd word en die doen dit echt vaak fout.

[bilbob]

vroeg of laat?
Het is dat ik niet eerder op die site gekeken heb maar dit is werkelijk het eerste dat ik zou proberen..

[Anoniem: 715452]

Hier is gewoon gefaald door een heel team. Een goede owasp test had dit al naar voren gebracht.

[slowdive]

Blijkbaar niet _elke_ developer...

Je kunt je ook afvragen waarom het na zoveel jaren kon kan. Programmeertalen zouden de mogelijkheid niet moeten hebben om dit zo te kunnen programmeren. Webbrowsers zouden dit soort data actief moet wegfilteren. Webstandaarden zouden moeten worden opgesteld vanuit een security-first principe.

Vanuit security-oogpunt is een toolkit waarmee alleen veilige software gebouwd kan worden daarom te preferen boven multipurpose talen waarmee "alles" kan.
In bepaalde sectoren (bijvoorbeeld rond betalingsverkeer) bestaan dit soort toolkits. Dus als het echt belangrijk is, kan het best.

[pofsok]

Ik denk niet dat je een GET request uit je webprogrammeertaal wilt filteren, aangezien de meeste websites van deze request gebruik maken en interactieve webnavigatie nogal lastig wordt zonder deze manier van data doorgeven. Het probleem is dat er niet geverifieerd wordt of diegene die de data opvraagt ook echt degene is die inlogt. Als je een beheerderspagina maakt, maar deze niet beveiligt met een wachtwoord oid, dan geef je toch ook niet de schuld aan de programmeertaal wanneer je "gehacked" wordt.

Dit lek is is echt een beginnersfout implementatie (14 jaar geleden had ik mijn eerste php - CMS systeem op deze manier geprogrammeerd, en kreeg nogal last van spam op mijn website. Hierdoor kreeg ik vrij snel de kwetsbaarheden van GET requests door wanneer je geen andere verificaties toeveogt.), en de developers moeten zich schamen.

[slowdive]

Het punt is dus dat de webstandaard zo zou moeten zijn dat je een GET (of een veiligere variant) niet op een onveilige manier kunt gebruiken. Ik begrijp dat de min(ners) niet verder denken dat dat ik ze de vrijheid van (bijvoorbeeld) PHP afneem, maar het maatschappelijk belang is niet dat de programmeur een tool met een hoge mate van vrijheid heeft, maar dat deze alleen veilige software kan schrijven.
Ik wil het de min(ners) ten spijt nog sterker formuleren. Programmeren in de traditionele vorm zal uiteindelijk niet te handhaven zijn in gebieden waar security kritisch is.
Wat kritisch is, is afhankelijk van de tijdgeest. Anno 2020 hebben we het dan over situaties waar niks mis mag gaan (militaire context , gezondheidszorg, banken), maar het zou wel eens kunnen dat de data van de gewone man van de straat daar over een tijd ook bijhoort, als je de groeiende kritiek op dataslurpers als Google mag geloven.

[pofsok]

Maar wat bedoel je met een onveilige manier? De get zelf is niet onveilig. De get en welke informatie er worden weergeven staan compleet los van elkaar. Privé informatie weergeven zonder goeie verificatie moet niet mogelijk zijn, maar aangezien wat we als privé informatie zien subjectief is (de usecase bepaalt wat en voor wie iets openbaar moet zijngastenboek is openbaar, pm is prive) kan je dat niet in de programmeertaal doen.

Ik begrijp je punt wel, maar als je het wil standaardiseren lijkt het mij veel logischer om naar de data opslag zelf te kijken. Bijvoorbeeld dat iedereen zijn eigen data beheert en zelf kan aangeven wat openbaar is, en voor welke informatie je bepaalde tokens oid nodig hebt.
Er zijn te veel usecases die niet met gevoelige data werken, en vaak zijn het combinaties van gevoelige en niet gevoelige data. Ik kan mij er zelf in ieder geval geen voorstelling maken van hoe je een programmeertaal flexibel kunt houden en het extreem in te perken.

[slowdive]

Als ik je reactie zo lees, begrijp je het dus heel goed.

De GET (als functie) en de betekenis van de data zijn twee losse factoren. De GET is het gereedschap, maar dat gereedschap zou niet met kwetsbare data mogen werken. Dat kan door de data op een goede manier te versleutelen, de programmeertaal zou het dus onmogelijk maken om met een GET niet-versleutelde data uit te wisselen. Het gereedschap moet dus slimmer worden. Als je met tools blijven werken die dit soort constructies mogelijk maken, blijven deze problemen terugkomen.

In een andere post in deze draad geef ik IRMA en het werk van Brenners Lee als voorbeeld van onderzoeksprojecten die proberen om de gebruiker te laten bepalen welke data vrijgegeven wordt in een bepaalde situatie.

[pofsok]

Volgens mij zitten we best wel op dezelfde lijn ja. Internet discussies zijn niet altijd even efficiënt, maar we komen er wel, zoals we nu zien. Nu daar nog een technologische oplossing op vinden!!!

[bilbob]

je zou toch mogen hopen dat mensen die betaald krijgen om de GET functie te implementeren snappen waar ze mee bezig zijn..

Een gasinstallatie installeren is ook gevaarlijk als je het fout doet.. daarom hebben we daar gecertificeerde mensen voor die bepaalde regels hanteren. Of dacht je dat dit foolproof is gemaakt?

[Anoniem: 718943]

De GET doet wat het moet doen, hetzelfde als een gasfitting dat doet. Dat moet niet veel complexer gaan worden, want complexiteit zorgt voor problemen.

Lijkt mij dat de security er omheen moet zitten, en dat zie je steeds meer gebeuren in de vorm van headers.
Je legt de focus op de verkeerde plaats.
De problemen zitten em in backwards compatibiliteit, want er zijn al zat mogelijkheden om gewoon goed veilige sites te bouwen. Alleen willen we al die oude meuk ook nog kunnen zien.

[robvanwijk]

het maatschappelijk belang is niet dat de programmeur een tool met een hoge mate van vrijheid heeft, maar dat deze alleen veilige software kan schrijven.

Laten we eens de vergelijking maken tussen "traditionele architecten" en software architecten. Het maatschappeljk belang is niet een architect met een hoge mate van vrijheid, maar eentje die alleen veilige gebouwen kan ontwerpen. Als mensheid hebben we inmiddels duizenden jaren ervaring met het maken van gebouwen. Maar tot op de dag van vandaag is het niet gelukt om tools te bouwen waarmee alleen veilige gebouwen ontworpen kunnen worden. Zelfs als we aardbevingen en sabotage niet meetellen, dan nog zijn er af en toe gebouwen en bruggen die opeens instorten. Als we sabotage wel meenemen (en dat lijkt me wel zo eerlijk, want dat is in feite wat een hacker is), dan denk ik niet dat je een architect zult vinden die een 100% garantie af zal durven geven voor zijn ontwerpen. Als we het in een vakgebied met duizenden jaren ervaring, waarbij blunders honderden doden per keer kunnen kosten, al niet voor elkaar krijgen, dan zie ik het niet lukken om deze mate van perfectie wel te bereiken in een vakgebied wat pas enkele tientallen jaren bestaat.

Programmeren in de traditionele vorm zal uiteindelijk niet te handhaven zijn in gebieden waar security kritisch is.

Als je bedoelt dat we overstappen van talen als C (waarin bijna alles mag) naar .net-achtige talen (waarin type safety en memory management uit handen worden genomen, zodat je daar geen fouten meer mee kunt maken), dan zou ik het met je eens kunnen zijn. Maar je claim ging over toolkits waarin je geen beveiligingsblunders kunt maken en sorry, ik geloof gewoon niet dat dat mogelijk is.

[Tozz]

Wel grappig.. Bij bouwwerken wordt de constructie getoetst door een constructeur. Die kijkt of het mooie plaatje van de architect ook veilig is. Of de vloer de belasting wel kan hebben, etc.

Een software constructeur zou wellicht een idee zijn

[robvanwijk]

Een software constructeur zou wellicht een idee zijn

Is dat niet waar we code reviews en tests voor hebben?

[pe0mot]

Inderdaad, maar waarom
- worden die op het eind van het project gepland en dus soms niet gedaan omdat we altijd te laat zijn?
- worden die niet gedaan omdat de competente mensen aan lucratieve projecten werken en de overheid "race to the bottom" tenders uitschrijft?
Assumption (er is een competente review) is the mother of all f****ups.

[Anoniem: 718943]

- Eind van het project? Dat is niet goed. Dat moet per opgeleverde stukje functionaliteit zijn.
- Niet gedaan? Het mag niet optioneel zijn.

Misschien is het probleem dat een hoop softwarebedrijven maar een beetje aan lopen te klooien.

[slowdive]

Over het eerste deel ben ik het met je eens. Als we terugkijken naar wat er in de tweede helft van de vorige eeuw aan code geproduceerd is, dan zouden we veel daarvan nu niet meer accepteren.
De IT is een jonge sector, wat we nu doen is over een halve eeuw niet te bevatten voor onze opvolgers.

De bouwkundige architect kan inderdaad nog onveilige constructies afleveren, maar de architect heeft dan ook geen vrijheden ingeleverd.
Als ik de architect zou verplichten om alleen met bewijsbaar veilige concepten te werken, zouden vloeren van parkeergarages niet meer in kunnen storten tijdens het bouwproces. Maar nogmaals, architecten zijn vrij en kunnen dus ontwerpen wat ze willen.
Zo zijn software-architecten ook vrij, en mijn punt is dus dat ze dat dus niet helemaal zouden moeten zijn.

Een voorbeeld waar je een taal zo kun aanpassen dat deze veiliger wordt zijn de prepared statements die sql-injectie onmogelijk maken.
Dit soort taalconstructies zouden er ook voor andere veiligheidsproblemen moeten zijn, maar dan niet door wat eenvoudige aanpassingen in de taal, maar door vanaf de basis de taal en zijn omgeving zo te ontwerpen dat deze alleen veilig gebruikt kan worden.

[Rutix]

Een voorbeeld waar je een taal zo kun aanpassen dat deze veiliger wordt zijn de prepared statements die sql-injectie onmogelijk maken.
Dit soort taalconstructies zouden er ook voor andere veiligheidsproblemen moeten zijn, maar dan niet door wat eenvoudige aanpassingen in de taal, maar door vanaf de basis de taal en zijn omgeving zo te ontwerpen dat deze alleen veilig gebruikt kan worden.

En dan nog kan als de programmeur een fout maakt die prepared statements zo worden gebruikt dat er data gelekt word. Er zal gewoon altijd nodig zijn dat mensen hun hersenen gebruiken en dat is hier gewoon niet gedaan.

[slowdive]

Volledig mee eens.
Het is nu al zo dat er behoorlijk wat gezonde hersens nodig zijn voor software development. Ik verwacht dat er in de toekomst gebieden zullen zijn waar nog veel meer gezonde hersens nodig zijn (meer traditionele software development), maar ook gebieden waar met blokkendozen/bouwpakketten veel meer gestandaardiseerd gewerkt wordt. De tijd zal het leren.

[robvanwijk]

De bouwkundige architect kan inderdaad nog onveilige constructies afleveren, maar de architect heeft dan ook geen vrijheden ingeleverd.

Mijn punt was dat als jouw voorstel "lever wat vrijheden in, heb gegarandeerde veiligheid" daadwerkelijk mogelijk was, dat het dan al lang en breed ingevoerd zou zijn in de bouwkunde. Of, omgedraaid, als het in de bouwkunde nog niet is ingevoerd, dan is de enige reden die ik daarvoor kan bedenken dat het simpelweg onmogelijk is.

Dit soort taalconstructies zouden er ook voor andere veiligheidsproblemen moeten zijn, maar dan niet door wat eenvoudige aanpassingen in de taal, maar door vanaf de basis de taal en zijn omgeving zo te ontwerpen dat deze alleen veilig gebruikt kan worden.

Er zullen vast een boel verbeteringen mogelijk zijn (en zolang die geen gigantische nadelen met zich meebrengen, dan ben ik er ook voorstander van om dat te doen). Maar ik geloof niets van jouw claim dat we met een nieuwe programmeertaal alle beveiligingsproblemen de wereld uit kunnen helpen. Zoals ik in een andere reactie zei, je programmeertaal (of dat nu C, PHP, Brainfuck of een toekomstige taal is die volgens jouw regels ontworpen is) heeft simpelweg geen manier om te zien dat er iets mis is met "domain.com/form?userid=123&entryid=456"; op technisch vlak is er simpelweg geen verschil tussen userid en entryid, beide zijn parameters. Hoe moet je programmeertaal of framework of toolkit of welke techniek dan ook, ooit vast gaan stellen dat de ene een potentieel beveiligingslek is, terwijl er met de andere niets mis is?

En dan hebben we ook nog een tweede probleem: de backend moet controleren dat de user inderdaad toegang heeft tot die entry... Je code dusdanig opzetten dat dat normaal gesproken automatisch goed gaat is nog wel te doen (hetzelfde geldt voor testen of dat inderdaad het geval is). Maar het zo opzetten dat zelfs een compleet incompetente programmeur (of nog lastiger, eentje die opzettelijk probeert een backdoor te bouwen) het niet fout kan doen zie ik niet gebeuren (en ook hier: hetzelfde geldt voor testen: ik zie niet voor me hoe een test kan controleren dat er nergens in je code een lek zit).

[Anoniem: 718943]

Alleen is dat niet het doel van prepared statements. Prepared statements zijn er voor om bulk data te verwerken zonder dat de optimizer elke keer zijn mening moet geven. Voor de wat meer dynamische queries wil je juist dat de optimizer zich er meer mee bemoeit.
Prepared statements zijn geen security feature, maar een performance feature.

Een hoop talen hebben query parameters, die prepared statements onmogelijk maken, die zijn ervoor bedoeld. Daarbij geef je de query op, en de parameters die ingevuld moeten worden, en de library die met de database praat zorgt ervoor dat er dan een query gefabriceerd wordt, met alle inachtneming van escaping e.d.

[slowdive]

Klopt. Prepared statement waren er dan ook al voordat duidelijk werd dat ze tevens ook veiliger zijn.
Ik gaf het voorbeeld omdat het laat zien dat er veilige en een onveilige manier van programmeren is. De taal zou alleen de veilige manier moeten aanbieden.

[incaz]

Dit was geen hack, dit was een keer hard op de vloer stampen. Die daarna instort, niet omdat er iets mis is met architectuur, maar omdat de aannemer substandaard rotzooi heeft gestort ipv zorgvuldig gegoten beton.

[robvanwijk]

Programmeertalen zouden de mogelijkheid niet moeten hebben om dit zo te kunnen programmeren. Webbrowsers zouden dit soort data actief moet wegfilteren.

Leuke theorie, maar technisch volkomen onmogelijk. Stel dat ik een site bouw met daarin een adres als "domain.com/form?userid=123&entryid=456". Die eerste parameter is een probleem (die zou afgeleid moeten worden uit mijn credentials), maar de tweede is volkomen legitiem (een enkele gebruiker kan prima toegang hebben tot meerdere objecten en dan zul je toch ergens aan moeten geven welke je wilt hebben). Vanuit technisch oogpunt is er echter geen enkel verschil, dus programmeertalen en browsers hebben geen enkele manier om te kiezen welke eruit gefilterd zou moeten worden en welke wel doorgegeven mag worden.

Vanuit security-oogpunt is een toolkit waarmee alleen veilige software gebouwd kan worden daarom te preferen boven multipurpose talen waarmee "alles" kan.
In bepaalde sectoren (bijvoorbeeld rond betalingsverkeer) bestaan dit soort toolkits. Dus als het echt belangrijk is, kan het best.

Citation needed. Geef eens een link naar zo'n magische toolkit die onveilige software perfect kan voorkomen?

[slowdive]

Misschien nu niet mogelijk met de huidige technologie, zoals PHP met de huidige webstandaarden. Maar notabene Brenners Lee zelf werkt aan een inherent veilig web.
Aan het beperken data-uitwisseling tot het hoogst noodzakelijk werkt bv. IRMA.
Gemalto (een Frans bedrijf met vestigingen in Nederland) gebruikt voor het maken van software toolkits. Ze krijgen die van de banken,. Je begrijpt dat hier geen link van is voor de gewone man.
Het maken van bewijsbaar veilige software is een belangrijk onderdeel in de informatica. Het onderzoek op dit gebied is zeer breed, maar een voorbeeld waar op Nederlandse universiteiten ook aan gewerkt wordt is model checking. Wiskundige modellen waarmee je de functie van de software omschrijft, van dat model bewijs je dan dat het correct is (en dus geen kwetsbaarheden bevat).

[robvanwijk]

Misschien nu niet mogelijk met de huidige technologie, zoals PHP met de huidige webstandaarden.

Mijn bezwaar geldt evengoed voor toekomstige technieken.

Maar notabene Brenners Lee zelf werkt aan een inherent veilig web.

Het "contract for the web" is een doelstelling, niet een technische oplossing waarmee die doelstellingen afgedwongen kunnen worden.

Aan het beperken data-uitwisseling tot het hoogst noodzakelijk werkt bv. IRMA.

Zou dat hier geholpen hebben? Op welk punt wordt die beperking afgedwongen? Als het alleen gaat om de communicatie tussen verschillende backend systemen dan zou het huidige lek nog steeds niet voorkomen zijn (de backend moet immers het user id weten). Alleen als dit tussen de frontend en de backend wordt gecontroleerd zou het mogelijk hebben kunnen helpen.

Het maken van bewijsbaar veilige software is een belangrijk onderdeel in de informatica.

Het maken van bewijsbaar correcte software ("geef correcte output voor correcte input") is al lastig genoeg. Bewijsbaar veilig is nog veel moeilijker; model checkers kunnen alleen controleren of een bepaalde formule wel of niet geldt voor een systeem. Dat betekent dat je "dit systeem is veilig" eerst uit zult moeten drukken in formules. Hoe had je dat in gedachte? Uitdrukken dat gebruiker Jantje geen toegang heeft tot gegevens die bij gebruiker Pietje horen is nog wel te doen, maar uitdrukken dat gebruiker Jantje niet kan doen alsof ie gebruiker Pietje is, dat is veel lastiger.

Het is prima mogelijk dat een systeem wel voldoet aan "je mag niet bij andermans gegevens", maar niet voldoet aan "je mag niet doen alsof je iemand anders bent". De tweede regel breekt de eerste regel namelijk niet, maar omzeilt die; dat is een cruciaal verschil. Een heel groot probleem bij model checkers is dat je nauwkeurig vast moet leggen wat je wilt controleren. Als je bijvoorbeeld wilt zeggen dat je systeem geen deadlock heeft, dan kun je zeggen dat het systeem geen bereikbare staat heeft, van waaruit het geen andere staat kan bereiken. Maar als het systeem een staat A kan bereiken van waaruit alleen staat B bereikbaar is, terwijl vanuit staat B alleen staat A bereikbaar is, dan zal de model checker zeggen dat er geen deadlock mogelijk is... Het is lastig genoeg als de ontwerper alleen hoeft te vechten tegen de enorme complexiteit van moderne systemen, maar voor "bewijsbaar veilig" moet je het gevecht aan met een intelligente tegenstander. Als je je systeem door een model checker hebt gehaald, dan moet een aanvaller niet meer op zoek naar een vergissing van de programmeur, maar naar een vergissing van zowel de programmeur als degene die de regels voor de model checker heeft geschreven. Daarmee heb je geen "toolkit waarmee alleen veilige software gebouwd kan worden", hooguit een toolkit waarmee alleen iets veiligere software gebouwd kan worden.

[slowdive]

Het stuk 'ik kan niet doen alsof ik Pietje ben' zit in IRMA. Althans voor normale situaties waarin ik mijn credentials veilig bewaar.
Natuurlijk kun je me het mes op de keel zetten, zodat ik jou vertel wie ik ben in de digitale wereld (waarna jij kan doen alsof jij mij bent). Die situatie is inderdaad heel moeilijk te voorkomen.

[roger128]

Op een hoog niveau snap ik de reactie, maar wat je aankaart komt neer op "De mogelijkheid om jezelf in je vingers te snijden uit messen bouwen". Dat gaat gewoon niet

[slowdive]

Het is dus de vraag of je messen moet gebruiken als je niet gesneden wil worden.
De tools waar ik naar verwijs in de bankaire sector werken toch echt zo. Volgens jouw metafoor: je kunt niet snijden, als dat niet de opdracht is.

Edit: missen=messen

[Reactie gewijzigd door slowdive op 23 juli 2024 15:56]

[Anoniem: 718943]

Het probleem in deze beeldspraak (ik heb een hekel aan beeldspraken, ze geven vaak aan dat er kennis mist om over de echte materie te kunnen praten) is dat ik ten aller tijden een mes kan kopen als ik wil.

Het probleem met de huidige situatie is dat het zo gegroeid is, en er zijn tig talen en frameworks die allemaal hun eigen design aanhouden, en de huidige software portofolio in gebruik, gemaakt in al die talen en frameworks is gigantisch. Je kunt nu niet zeggen, we gaan het anders doen, die luxe hebben we niet.

Tuurlijk zal er ergens wel eens een goed initiatiefje naar boven komen voor privacy, maar zo lang alle andere tools, talen en frameworks blijven bestaan, blijven ze in gebruik.

[R.di.Giovanni]

Het zou mooi zijn als er een soort veiligheidskeurmerk zou zijn dat aangeeft dat een app of website grondig is gecontroleert op security aspecten. En nog mooier als de overheid zichzelf dan zou verplichten eerst zo'n keurmerk te behalen alvorens een app of site vrij te geven waar gegevens van burgers worden gebruikt.

[The Zep Man]

Het zou mooi zijn als er een soort veiligheidskeurmerk zou zijn dat aangeeft dat een app of website grondig is gecontroleert op security aspecten.

Copy/Paste, klaar. En wat nu veilig is hoeft later niet veilig te zijn.

Het enige dat werkt is als het lekken van gegevens meer pijn doet dan het beschermen ervan. Ik heb er wel eens vaker naar gelinkt: de Sarbanes–Oxley Act. Bij een foute boekhouding volgen er straffen, en sinds de invoering ervan hebben bedrijven hun boekhouding tot in de puntjes op orde.

Hetzelfde kan je doen met informatiebeveiliging. Zorg ervoor dat bedrijven hun informatiebeveiliging op orde hebben omdat bij nalatigheid verantwoordelijken persoonlijk gestraft worden.

[Reactie gewijzigd door The Zep Man op 23 juli 2024 15:56]

[Daoka]

Copy/Paste, klaar. En wat nu veilig is hoeft later niet veilig te zijn

Er zou een systeem kunnen komen waar je op hun website een controle kan doen. Uiteraard moet je dan wel zelf naar de website gaan en mag de veiligheidskeurmerk geen link bevatten om directe links naar valse websites te voorkomen. En voor de veiligheidskeurmerk moet een korte kleine adres komen waar moeilijk de letters van te vervalsen zijn. Dus geen i o of l die ik zo even kan bedenken. vwc.net (veilige website certificaat) (geen .nl of .com dus vanwege de l en o).

[supersnathan94]

Gaat niet werken. De w en t hebben een cyrilisch equivalent wat er wel op lijkt maar in UTF dus wel een kompleet ander karakter is.

Het cyrillische alfabet heeft 11 van dat soort karakters. Echter werkt het dus ook met bijvoorbeeld een c icm l, j en i icm met bepaalde fonts (Tahoma in XP). Dan krijg je homoglyphen die lijken op d, g en a. Het is dus helemaal niet zo makkelijk als je denkt.

[Daoka]

Ik denk dat er best een mogelijkheid zou zijn. Misschien een simpele domein als abc (wat verder niets betekent maar makkelijk te onthouden is en snel in te voeren) speciaal gereserveerd en nooit door een ander. Dus dat .nl .com .co.uk. net .org .alleswatjekanverzinnen allemaal niet gebruikt mag worden door het publiek. Laat elke browser standaard de certificaat van deze domein in programmeren zodat die nooit verwijderd kan worden of overschreven. Laat ze ook een paar mogelijk spelfouten domeinen registreren zoals in geval van de abc domein ab. ac. bc. En misschien nog een paar dingen wat ik nu niet kan bedenken.

Of misschien een app standaard geïnstalleerd op de telefoon die niet te verwijderen is en altijd kijkt naar updates die verplicht geïnstalleerd wordt. En de website certificaat met qr code kunnen scannen.

Elke website is natuurlijk anders gebouwd en heeft dus andere mogelijke lekken waardoor het natuurlijk nooit 100% veilig zal zijn. Maar ze kunnen ieder geval wel een hoop dingen testen zoals dat op dat moment de laatste versies geïnstalleerd zijn, wachtwoorden goed opgeslagen hun certificaat in orde en nog meer veel gemaakte fouten. Ik verwacht alleen dat mensen dit te weinig zullen gebruiken om er echt iets aan te hebben. Maar ik zie het wel mogelijk.

[supersnathan94]

Maar dat kan gewoonweg niet. Hostnames zijn goedkoop doordat er veel van worden verkocht iedere TLD wordt uitgegeven richting de beheerder en die bepaalt gewoon simpelweg dat iedere gek die ervoor betaald een domein naam kan krijgen. Je moet dan dus met al die partijen wereldwijd gaan afspreken dat ze abc.<tld> niet meer uit mogen geven. Dat gaat gewoon niet.

Of misschien een app standaard geïnstalleerd op de telefoon die niet te verwijderen is en altijd kijkt naar updates die verplicht geïnstalleerd wordt. En de website certificaat met qr code kunnen scannen.

dat heet bloatware en daar zit niemand op te wachten.

Laat elke browser standaard de certificaat van deze domein in programmeren zodat die nooit verwijderd kan worden of overschreven. Laat ze ook een paar mogelijk spelfouten domeinen registreren zoals in geval van de abc domein ab. ac. bc. En misschien nog een paar dingen wat ik nu niet kan bedenken.

Voor het certificaat heb je HSTS. Wordt al actief gebruikt.

Mbt spelfouten. Dat heet typosquatting en wordt al gedaan. Het kost echter buitenproportioneel veel geld om iedere mogelijke typo te registreren.

[Daoka]

Maar dat kan gewoonweg niet. Hostnames zijn goedkoop doordat er veel van worden verkocht iedere TLD wordt uitgegeven richting de beheerder en die bepaalt gewoon simpelweg dat iedere gek die ervoor betaald een domein naam kan krijgen. Je moet dan dus met al die partijen wereldwijd gaan afspreken dat ze abc.<tld> niet meer uit mogen geven. Dat gaat gewoon niet.

Dank je ik wist niet dat dit TLD heet.
Waarom zou dit niet gaan? De ip range 192.168 is toch ook wereldwijd gereserveerd voor interne netwerken. Het kost misschien even tijd maar onmogelijk zeker niet. Het is alleen de vraag misschien van wil elke partij meewerken. Maar als ieder geval al alle op dit moment mogelijke TLDs gereserveerd zijn dan kunnen ze daar ieder geval niets meer mee.

[...]
dat heet bloatware en daar zit niemand op te wachten.

Mensen zitten niet te wachten op bloatware. Al zijn er natuurlijk genoeg standaard dingen op die niet te verwijderen zijn maar toch niet als bloatware gezien wordt omdat dit nuttig is (al verschilt dit natuurlijk per mens). Maar dit heb ik toegevoegd zodat je nooit in de store hoeft te kijken naar de app en mogelijk een valse app kan installeren die hoger in de lijst komt omdat ze gekochte stemmen en downloads hebben. En het is ook nog een 2e beveiliging. Dan moeten ze wel 2 apparaten hebben gehackt of besmet om het onveilig te maken.

[...]
Voor het certificaat heb je HSTS. Wordt al actief gebruikt.

Mbt spelfouten. Dat heet typosquatting en wordt al gedaan. Het kost echter buitenproportioneel veel geld om iedere mogelijke typo te registreren.

Nee ik bedoel niet HSTS. Ik bedoel echt dat de certificaat gewoon ingebouwd wordt in de browsers of zo goed beveiligd wordt dat deze nooit aan te passen is of te verwijderen. En dat die dan in elke update van de browsers voor veiligheid opnieuw geïnstalleerd / vernieuwd wordt.

En typosquatting (nogmaals dank je) is duur. Maar dat is natuurlijk elke beveiliging. Hoe korter de website adres hoe minder websites ze hiervoor hoeven te registreren.

Edit: En misschien kan het landelijk / wettelijk aangepast worden dat al die TLDs en die typosquatting sites niet gebruikt mogen worden. Dan kost het op die vlak ook geen geld meer.

[Reactie gewijzigd door Daoka op 23 juli 2024 15:56]

[supersnathan94]

Dat gaat niet, omdat er geen standaard voor is. Die IP ranges zijn al vanaf het begin van interne netwerken gestandaardiseerd. Daar moet je het mee doen zeg maar.

Ik snap je punten wel hoor maar er zitten behoorlijk veel mitsen en maren aan. Stel je doet dit voor overheids instanties. Je wil dit ook voor bijvoorbeeld banken. Even later ziekenhuizen en zorgverleners. Op een gegeven moment is het hek een beetje van de dam. Al het syncen en afspreken van welke domeinen dan niet meer gebruikt mogen worden onder andere TLD’s moet dan gestandaardiseerd worden en gaat heel veel tijd en moeite kost. Dat geld moet ergens vandaan komen.

Daarnaast heb je ook dingen als URI en URL strategieën die subdomeinen en lange paden vereisen (kijk bijvoorbeeld eens naar de Domeinen van de nederlandse basisregistraties of de nieuwe omgevingswet domeinen). Dat wordt een miljarden exercitie.

[erikmeuk3]

Jaren lang hebben ze er op op gehamerd als er een slotje staat is het goed.
Daar zijn we inmiddels achter dat dit helemaal niet zo is.
Het aantal sites van de overheid met 100% score op internet.nl stijgt.
Maar voor dit soort blunders is volgens mij geen test voor te maken.

[elmuerte]

sinds de invoering ervan hebben bedrijven hun boekhouding tot in de puntjes op orde.

Op orde, maar niet perse naar waarheid. Er zijn genoeg bedrijven, CFOs, accountants, etc. die de SOX overtreden hebben, en daarvoor gestraft zijn.

Hetzelfde kan je doen met informatiebeveiliging. Zorg ervoor dat bedrijven hun informatiebeveiliging op orde hebben omdat bij nalatigheid verantwoordelijken persoonlijk gestraft worden.

Hier is geen geval van nalatigheid geweest, maar incompetentie. Equifax was een voorbeeld van nalatigheid. Maar de meeste datalekker zijn niet het resultaat van nalatigheid.

[CEx]

Is het niet nalatig als je een incompetent bedrijf inhuurt?

[larsiey]

De SOx is ingevoerd doordat voorafgaand grote boekhoudschandalen zijn gepleegd.
Door bijvoorbeeld het Eron schandaal. Hierdoor zijn zowel Enron als de controlerend accountant van Enron, Arthur Andersen, van de aardbodem verdwenen. Beide waren miljarden organisaties die fraude pleegden.

Dat is natuurlijk wat anders dan zo'n relatief klein foutje als waar dit artikel over gaat.

[adje123]

Reactie niet meer relevant na uitleg van Tijs hieronder.

[Reactie gewijzigd door adje123 op 23 juli 2024 15:56]

[TijsZonderH]

Dat hoeft niet persé erg te zijn. In sommige gevallen reageren bedrijven juist sneller als media bij ze aankloppen dan wanneer een beveiligingsonderzoeker dat doet (al weet ik niet hoe dat zit bij het RIVM, denk dat die normaal ook wel snel reageren).

Media horen ook aan responsible disclosure te doen, dus tijd geven om een lek te dichten. Dat doet de NOS ook, en hebben ze hier ook gedaan.

Bovendien ging het in dit geval snel. Joost, de NOS-redacteur, hoorde er vanochtend van, heeft het RIVM ingelicht (na een check), en de site is dezelfde dag offline gehaald én er is daarna een artikel van geschreven. Dat lijkt mij een prima tijdlijn zo, ik denk niet dat een beveiligingsonderzoeker daar zelf sneller mee was geweest.

[adje123]

ok, dat is duidelijk.

Waarom wordt zo'n tijdslijn niet in het artikel gezet? Of tenminste uitgelegd dat het dichten erg snel voor elkaar was? Nu krijgt men(ik) een beetje een rare smaak in mijn mond hierover. Ik snap dat het sensatie is voor nieuwsbedrijven maar het is ook wel eens fijn om te lezen dat het constanteren en dichten van het lek matter of hours was ;-)

[erikmeuk3]

Ik heb jaren geleden een lek gemeld over de overheid.
Er een gesprek over gehad met de verantwoordelijke.

Na een paar dagen.
Het is nooit gebeurt.

[Anoniem: 310408]

Vertel ons precies wel lek het was en laat ons zien dat het nog steeds open is ( (na jaren mag je er gewoon openbaarheid aan geven) en we geloven je.

[erikmeuk3]

DigiD
Ik moest inloggen bij mijn gemeente om wat documenten te downloaden
Het viel me op dat ik 2 keer moest uitloggen.
Ik kon nu ook bij andere instanties naar binnen zonder in te loggen.
En dat bleef open, als je 1 keer uitlogt. De idle time-out van 15 minuten werkte wel.
De fout is wel hersteld.

[Bsandro]

Same here, datalek gemeld bij een grote zorginstelling en met de verantwoordelijke gesproken. Uiteindelijk als klacht gemeld bij AP,


Het is nooit gebeurd......

[t link]

ethisch gezien is het inderdaad niet erg, of het wettelijk gezien mag is een ander verhaal.

[TijsZonderH]

Wat zou er niet wettelijk aan zijn?

[jpsch]

Henk Krol is hier voor zoiets veroordeeld.

https://www.nu.nl/interne...-krijgt-boete-hacken.html

[TijsZonderH]

Dat was omdat het hacken niet proportioneel was. Hij keek bv een tweede keer in het systeem nadat hij al na een keer had aangetoond dat er een lek zat. Je kunt onder de noemer van journalistiek prima een systeem testen zoals de NOS dat nu heeft gedaan, zie hun verantwoording onderaan het stuk. Daarin leggen ze uit wat ze hebben getest, en op welk moment ze redelijkerwijs konden bewijzen dat het lek er zit.

[jpsch]

Vraag 't me af als 't echt voor de rechter komt.

Maar goed dat er een waarschuwing is voor de gegevens vergaring rondom Covid en hopelijk iedereen op scherp staat.

[Anoniem: 310408]

Vraag 't me af als 't echt voor de rechter komt.

Maar welke wet is er dan overtreden? Alle informatie die we nu hebben lijkt erop te duiden dat alles prima is verlopen. Als jij ander informatie hebt dan je duim of onderbuik denkt ik dat dit het moment is om het te delen.

[t link]

Van wat ik weet is responsible disclosure alleen bedoelt naar het bedrijf dat er last van heeft, en is het absoluut niet de bedoeling dat je de info met derde deelt. het zit al op de rand met dat er actief gescraped is wat technisch gezien al niet voldoet aan de nederlandse eis dat je niet meer doet dan nodig om aan te tonen dat het fout zit.

[robvanwijk]

Van wat ik weet is responsible disclosure alleen bedoelt naar het bedrijf dat er last van heeft, en is het absoluut niet de bedoeling dat je de info met derde deelt

Je deelt het niet totdat het is opgelost (of, totdat er zo lang niets gebeurt dat openbaar maken de enige manier is om te zorgen dat het opgelost wordt).

In een andere post van Tijs (de "grootvader" van de post waarop je reageert) wordt precies uitgelegd wat er gebeurd is. Als iedereen heel snel reageert (zoals in dit geval) dan is niet alleen de tijd tussen ontdekken en oplossen kort, maar dan kan ook de tijd tussen ontdekken en publiceren erg kort zijn.

[Zumbrink]

Erg jammer?
Een site van een overheidsdienst die persoonsgegevens inclusief medische data laat uitlekken heeft terecht nieuwswaarde lijkt me.

[adje123]

ik zeg toch ook niet dat het geen nieuwswaarde heeft? Je kan toch prima eerst de overheid inlichten en daarna pas de NOS etc....?

[Stef42]

Waarom perse in die volgorde? Het hele onderwerp ligt onder een vergrootglas, het is een overheidswebsite en het betreft gevoelige informatie. Daar verdient een burger goed over geïnformeerd te worden.

[adje123]

Het is heel simpel. Een NOS kan er niet voor zorgen dat de formulieren a la minute offline gaan. De beheerder van de site kan dat wel. NOS gaat eerst zelf ook nog onderzoek doen, schrijft een artikel, laat dat revieuwen en voor je het weet ben je weer een week of langer verder? Als hij dit eerst bij de overheid had gemeld en daarna bij het NOS dan was het formulier sneller offline.

[Daoka]

Het had misschien beter geweest. Aan de andere kant door er groter aandacht zullen ze de druk ervan sneller voelen dan dat 1 persoon een bericht stuurt. Vooral nu in het weekend dat ze misschien niet zo actief kijken naar emails of misschien denken ze wel van de beheerder is vrij dus komt het maandag wel. Uiteraard weet ik niet hoe het daar gaat maar dus dit zijn maar 2 mogelijke situaties.

[TijsZonderH]

Zoals ik hieronder ook al schreef is het formulier dezelfde dag nog offline gehaald én is er een artikel van verschenen.

[supersnathan94]

Voordat het de beheerder van de site heeft bereikt ben je een aardig eind verder hoor. Dit soort dingen lopen via het NCSC en dan komt het op een backlog. Vaak hebben nieuwsbedrijven als NOS mogelijkheden om veel sneller contact te leggen met de betreffende instanties. Zij zullen dit dan ook niet direct a la minuut naar buiten brengen maar eerst melden en schakelen met die instantie.

Zo blijkt ook uit het artikel. NOS heeft het geverifieerd en direct RIVM op de hoogte gebracht.

[arjankoole]

Geïnformeerd ja, NA responsible disclosure.

[Stoney3K]

Als je het gelijktijdig doet maakt dat niet uit.

Als je éérst naar de overheid stapt en het meldt, heb je kans dat ze gewoon zeggen dat je je bek er over moet houden. En dan mag je maar hopen dat ze het probleem fixen.

[Anoniem: 718943]

Pas op met dit soort adviezen.
Er zijn heel veel valkuilen in het proces, en het zijn er een heleboel die tot inmenging van de OvJ kunnen leiden.

[Horatius]

Ik heb niet de contacten bij het RIVM die de NOS heeft, het is waarschijnlijk veel sneller gedicht omdat er zoveel druk opstaat. Het is vaak genoeg voorgekomen dat een bezorgde burger iets vindt en het veel te lang duurt voordat er echt iets gebeurt.

[adje123]

Snap ik. Uitleg van Tijs(auteur) plaatst het bericht in een ander daglicht. Uit het nieuwsbericht kan je niet opmaken dat het allemaal zo snel geregeld is, dat is erg jammer want juist in deze tijden is een positief geluid uit deze hoek zeer welkom. Maar goed, zoals ik ook al als reactie gaf bij de auteur van het artikel, ik snap ook wel dat sensatie er bij hoort.

Mijn opvatting over de gang van zaken is bij deze bijgesteld.

[Reactie gewijzigd door adje123 op 23 juli 2024 15:56]

[kodak]

Wat ik niet begrijp is dat zowel de ontdekker als de journalist wisten dat het gevoelige (medische) gegevens waren en vervolgens wel geautomatiseerd van maar liefst 43 andere personen de gegevens downloaden. Klinkt niet proportioneel. Ze hadden ook na 5 resultaten al kunnen stoppen om te bewijzen dat het geautomatiseerd kon. Het zijn tenslotte wel andermans persoonsgegevens met medische informatie. Dat doet behoorlijk af aan de ethische kant.

[Anoniem: 310408]

Maar wat voordeel zou de journalist kunnen hebben om die data te hebben? Ik zie niet veel problemen.

[kodak]

Als er geen voordeel in zit dan hebben ze het ook niet nodig. Het lijkt me ook de verkeerde kant om het te bekijken. Het belangrijkste hier lijkt me het beschermen van de personen en hun gegevens. Ook als ontdekker of journalist. De personen die met hun persoonlijke (medische) gegevens mee doen moeten er ook bij ontdekken of journalistiek op kunnen vertrouwen dat ze bescherming hebben. Dat begint bij het niet onnodig downloaden. Als ze de gegevens niet onnodig hebben dan heeft het ook minder gevolgen voor de personen van wie de gegevens zijn. Het was echt niet nodig om een aantal minuten maar te gaan downloaden en alles te verzamelen wat er in die tijd van anderen aan (medische) persoonlijke gegevens beschikbaar was.

[mrmrmr]

@kodak: ik zie je punt en ik heb sympathie voor de slachtoffers, maar technisch gezien heeft het nut om meer aanvragen te doen. Daarmee kun je aantonen dat nummers in volgorde worden uitgegeven en je kunt zien of het aantal aanvragen (queries) wordt beperkt. Die twee dingen duiden op nog grotere ontwerp- en implementatiefouten.

De grootste beveiligingsfout is natuurlijk dat er geen persoonsgebonden databeveiliging was en dat de maker en ontwerper van deze site onbekwaam is. De vraag is vervolgens waarom de RIVM dat niet ingezien heeft. De beveiliging van de site is kennelijk ook niet doorgelicht door een onafhankelijke partij. Dat kun je zo vaststellen omdat dit de allereerste methode is die elke "hacker" probeert. Zo'n "aanval" uitvoeren kan bijna iedereen: de enige vereiste vaardigheden zijn het om kunnen gaan met een browser en het bezit van een dosis gezond verstand.

De RIVM faalt in het opdrachtgeverschap. Aangezien ze werken met veel persoonsgegevens moeten ze onder curatele worden gesteld. Dit kan zo niet langer. De minister zou daarvoor de juiste (niet-politieke) deskundige personen moeten inschakelen voor het ontwerp- en uitvoeringswerk en dat laten controleren door een onafhankelijke partij.

[Reactie gewijzigd door mrmrmr op 23 juli 2024 15:56]

[kodak]

Het nut had ook bewezen kunnen worden door resultaten automatisch op te vragen en na een klein aantal resultaten te stoppen. Er zaten kennelijk gegevens in waaraan gezocht resultaat was te herkennen, tel die tot een maximum en het was voldoende bewezen. Het lijkt nu dat ze een bepaalde tijd hebben genomen zonder zich te bekommeren om hoeveel gegevens ze konden krijgen. Als er zo veel bekommering is om het lekken dan zorg je als ontdekker of journalist er ook voor dat je zelf niet te veel persoonlijke gegevens download. Ook als je wil bewijzen of het downloaden geautomatiseerd zou kunnen.

[Anoniem: 718943]

Volgens mij is het downloaden an sich al strafbaar, want het is niet nodig om het lek aan te tonen, het is gelijk misbruik maken van het lek.

[wildhagen]

Dit gaat de acceptatie van de corona-app natuurlijk niet bepaald ten goede komen. Als ze de site al onvoldoende beveiligen, is er dan reden om aan te nemen dat de app wél veilig zal zijn?

Ik denk dat ik huiverig ben om die app te installeren, gezien dit bericht. Ik zit er niet op te wachten dat straks iedereen mijn gegevens kan opvragen, als ook in die app zo'n lek blijkt te zitten.

[robvanwijk]

Als ze de site al onvoldoende beveiligen, is er dan reden om aan te nemen dat de app wél veilig zal zijn?

De twee systemen hebben werkelijk niets met elkaar te maken; als de ene slecht beveiligd is zegt dat niets over de beveiliging van de andere. Kijk naar SpaceX: hun prototype ontploft maar een paar dagen later gaat de bemande lancering gewoon door. Daar geldt precies hetzelfde: de menselijke hersenen leggen een verband tussen twee dingen dat er simpelweg niet is.

Dit gaat de acceptatie van de corona-app natuurlijk niet bepaald ten goede komen.

Ik vrees dat je hier volkomen gelijk hebt. Zelfs al is er geen goede reden voor, dan nog is dit effect erg waarschijnlijk.

[vannilesoep]

Worden beide systemen dan niet in opdracht van (of in ieder geval in nauwe samenwerking met) het RIVM ontwikkeld?

Als bij het ene systeem er dermate weinig energie in is gestoken om het te testen op kwetsbaarheden, waarom zou dat dan bij het andere systeem wel zo zijn?

Je vergelijking met SpaceX lijkt in de eerste instantie een goede, maar je ziet over het hoofd dat het ontploffen van de raket juist tijdens testen en in een ontwikkelfase gebeurde.

Deze kwetsbaarheid in de website is wat mij betreft reden tot een gegronde mate van wantrouwen richting een app. De technologie waarop dergelijke apps gebaseerd zijn is prima en er kan een degelijke en veilige app ontwikkeld worden. Net zoals de technologie voor opslag van gevoelige informatie in een backend er is, ook hier bestaat de mogelijkheid een veilige app te bouwen. Dat je vervolgens verzaakt de meest elementaire beveiligingsmechanismen in te bouwen geeft reden tot wantrouwen.

[Anoniem: 718943]

Het RIVM legt enkel de acceptatie criteria weg, ik begrijp dat de app en de site 2 verschillende leveranciers zijn. Dus de kwaliteit kan gewoonweg enorm verschillen tussen die 2, zelfs met dezelfde criteria vanuit de opdrachtgever.

Het RIVM gaat er gewoon vanuit dat bedrijven die je inschakelt om hun werk te doen competent zijn in hun vakgebied, en dat is (vooral in de software) niet altijd het geval.

[vannilesoep]

Wanneer het RIVM er zonder meer vanuit gaat dat de ingeschakelde bedrijven competent zijn, is dit des te meer reden een gezonde dosis argwaan te hebben voor ontwikkelde software door die bedrijven.

[WhatsappHack]

Hopelijk gebruiken ze de Apple/Google-API, dat zou al een aantal zorgen wegnemen en daar zitten wat waarborgen in.

[hydex]

Zou fijn zijn als die onderzoekers de complete lijst die zij altijd aflopen om dit soort formuliertjes te testen openbaar zouden maken of als dat mensen op ideeën zet dat je een formulier langs een online test straat kan halen. Net zoals dat je html kunt valideren. En dat er een groen vinkje komt met veilig of niet.

En daarnaast zou ik een super veilige kluis willen hebben waar mijn identiteit in staat en dat als ik mij aanmeld op een willekeurige website en die heeft naam, adres etc nodig dat dit via die kluis gaat. Ze kunnen het opvragen maar niet opslaan. Nu staan mijn gegevens overal totaal niet wenselijk.

[Gotiniens]

https://owasp.org/www-project-top-ten/

Ik ben geen expert, maar ik zou zeggen dat dit onder nummer 2 of 3 valt

[Anoniem: 718943]

'Ze kunnen het opvragen maar niet opslaan'.
Hoe zou dat dan in zijn werk moeten gaan? Opvragen is immers altijd de data naar je toe halen, en als je de data hebt, kun je het opslaan, de controle zijn ze aan de andere kant dan kwijt.

[MrMonkE]

Echt ongelofelijk. Client side ID's .. in de querystring zelfs.. is dit een artikel uit 1998 ofzo?
Heb ik de laatste 22 jaar gedroomd over alle grote bedrijven die voor de overheid werken omdat kleine partijen niet voldoende kennis in huis hebben?

[Stoney3K]

Lijkt me een implementatie met het bekende mantra: "You want it secure, cheap, fast. Pick two."

Dat een ontwikkelaar zoiets op deze manier in elkaar klust als het morgen af moet met het budget van een schoenveter, dat snap ik ook nog wel...

[incaz]

Dat geldt wellicht voor complete systemen nog wel, maar een enkel formulier is met een fatsoenlijk framework (en zelfs met veel minder fatsoenlijke) zo gemaakt, en keurig voorzien van goede beveliging.

We hoeven dit soort dingen inmiddels al helemaal niet meer goed te praten.
(En dat kan dus echt in een ochtend, door een stagiaire met een paar maandjes framework experience, en met gebruikmaking van open source frameworks als je zou willen.)

[Reactie gewijzigd door incaz op 23 juli 2024 15:56]

[Anoniem: 718943]

Muggenzifterij:

Het mantra is 'Good, Cheap, Fast', gaat niet specifiek over security, want iets kan veilig zijn, maar nog steeds troep.

[0xygen500]

Is 128x niet wat veel verzoeken? Valt dat nog onder het ethische?

[jpsch]

Meer dan één is al te veel volgens de rechter.

quote: Ook had de journalist niet een tweede keer in het systeem mogen gaan. "Krol heeft de grenzen van proportionaliteit overschreden.".

https://www.nu.nl/interne...-krijgt-boete-hacken.html

[Arnoud Engelfriet]

Het hangt af van waarom je er 128 moet doen. Wat is je journalistieke reden, wat moet je aantonen? Hier was het vermoeden dat het ID van de gebruiker in de querystring stond, en dat je door querystringmanipulatie dus andere gebruikers kon opvragen. Dat verifieer je alleen maar door een batch ID's te proberen.

Henk Krol had het lek keurig aangetoond en gemeld, en belde daarná Omroep Brabant om voor de camera's nog een keer te laten zien waar het lek zat. Ik zie daar nul journalistieke reden voor. Dat je graag on camera wilt laten zien wat je hebt gevonden is leuk, maar niet met andermans privédata.

Vonnis: https://www.itenrecht.nl/...92-12%20(Henk%20Krol).pdf