Je verwacht zoiets natuurlijk niet.

Nou dat geeft weer veel vertrouwen in het RIVM (lees overheid) als het over ICT zaken gaat. Enkel een nummer in de hyperlink van het invulformulier wijzigen was voldoende om iemand anders gegevens te achterhalen! Daar hoef je geen doorgewinterde hacker voor te zijn.
De verantwoordelijke minister was nog niet bereikbaar voor commentaar aldus de NOS.

Geen probleem, het is maar privacy gevoellige informatie en privacy bestaat niet meer als je sommige moet geloven.

Zovér mogelijk vandaan blijven dus. Ook geen corona-app oid, waar ze nu gewoon op azen. Data, geld en vals vertrouwen: Dat monster moet je gewoon NIET voeden. En ze hebben nooit afstand genomen van fraudeur Ab Osterhaus en dat zou genoeg moeten zeggen, met z'n 'mexicaanse griep'...

Dat is een geweldige hack, die heeft nog NOOIT iemand eerder geprobeert,

Te banaal voor woorden.

Tja desde meer een reden om geen corona app te installeren.

Dat valt onder hetzelfde ministerie wat die corona-app probeert door te drammen, is het niet?

Een foutje is zo gemaakt en zal ik geen developer kwalijk nemen, de alwetende developer bestaat namelijk niet.

Maar potverdorie, mijn zoontje van 10 die later hacker wil worden, heeft dit soort trucjes om de URL aan te passen gewoon zelf bedacht en zat zomaar op de pagina van zijn klasgenoten en hoe leuk op de pagina van de leraar.

Gelukkig hadden allen die hier reageren het veel beter gedaan, bij een website die snel moest worden opgezet, onder grote tijdsdruk. Al die geniale IT-ers hier, die op gebied van beveiliging zelf nimmer een steek zullen laten vallen. LOL....

Ik was dus niet de enige die dit opviel. Weg met pek en veren zo'n man.

https://sevenxseven.wordpress.com/2009/08/14/panic-sells/

Geen password of 2fA beveiliging oid?

Maar ja, tijdens een pandemie heeft het RIVM (de overheid) blijkbaar geen aandacht voor security.
Waarom ook. Niemand anders heeft interesse in dit soort gegevens, toch?

Net als de data die via de API's van Google en Apple loopt.
Daar hebben die bedrijven ook geen enkele interesse in.
Dat past helemaal niet bij hun business-model.
Oh, wacht....

Bij de manier waarom organisaties (JBZ, RIVM) en delen van de bevolking (bv samenklonteren tijdens een pandemie, vechtpartijen bij een zwemplas, poolonaise in cafe's) met de veiligheid van anderen omgaan, toont aan dat het "Grote Ik" heerst bij die groepen mensen en organisaties.
Het blijkt maar weer dat je zo gedwongen wordt om dan maar zelf voor je eigen veiligheid te zorgen.
Dus niet meedoen aan dit soort dashboards, de corona-app, of het delen van persoonlijke informatie met anderen. Groepen van die anderen tonen keer op keer maar weer dat ze het vertrouwen niet waard zijn.

Er is nog wel een verschil tussen "een steek laten vallen" en deze banale fout die elke handige middelbare scholier al weet te vinden.

Gewoon inloggen met DigiD verplichten.
Heb je geen computer of smartphone? Geen probleem. Ga naar de bibliotheek bij je in de buurt (met het openbaar vervoer) en laat iemand je daar helpen met DigiD.

Hoe zit het nou met een eenduidig beoordeling-kader voor de gezochte slimme oplossing(en)?

Minimaal sinds 14 mei is er denk ik al veel aanleiding om meer energie in het breder en alles omvattend uitzoeken en borgen van de security en privacy van het traject dat het ministerie zich wenst.
Dat betreft een intieel onderzoek en rapportage ervan bevat een paar belangrijke relevante opmerkingen.
KPMG meldde in - Securitytest potentiële Corona-apps Ministerie van - al over de "Deelonderzoek met beperkte diepgang":
1) "Tijdens ons onderzoek hebben wij de gebruikte apps, de backend alsmede communicatie tussen de componenten met een beperkte diepgang kunnen onderzoeken (als gevolg van de korte tijdslijnen)."

2) Als hoogste prioriteit noemt KPMG in kader van haar onderzoek:
" Kan een kwaadwillende gevoelige informatie bemachtigen door het ongeautoriseerd kunnen communiceren met de achterliggende infrastructuur van applicatie X?"

Dat na de officiële lancering van de infectie radar kennelijk ook een issue door het ministerie van VWS is opgemerkt, maar door derden, wijst duidelijk op het niet VOORAF volledig willen of kunnen borgen van aangereikte adviezen en adviezen door het ministerie van VWS c.q. de minister in relatie tot haar software leveranciers.
Is de set van technische en functionele eisen kader voor toepassingen die in kader van Corona worden ingezet nog bijgewerkt en versterkt sinds de bevindingen van KPMG (14 mei 2020) of niet?
Was er sinds 14 mei 2020 na het KPMG advies een opdracht uitgegaan om de infectie-radar website zelf al offline te halen?


Nu duikt er bij de infectie-radar dus "Een kwetsbaarheid die ook bekend staat als Insecure Direct Object Reference (IDOR)" op.
Dat is nota bene NA live gaan van de website via de PUBLIEKE webserver voor bredere ontsluiting.
Dat is echt tekenend en zorgelijk.
Met een professionele uitrol merk je en verhelp je de kans op zoiets natuurlijk al voor het publiekelijk live gaan.
Namelijk door toepassing in de test-fase met een set van voor NIET-breed publiekelijk ingezette webserver verificaties en validaties.
Kennelijk schortte het daar sinds 17 maart 2020 (en dus daarvoor ook al) aan, of ging er in het toepassen van de eerdere bevindingen iets ernstig mis.
Dit betreft ook het mijn inziens in risico-toetsingkader verband voor privacy dat vanuit de AVG op orde zou moeten zijn.
Daar zijn toch talloze opmerkingen en toezeggingen voor gedaan.
Het ministerie heeft dit sinds het live gaan voor breed publiek de euvels dus niet zelf al willen/kunnen verhelpen.

Dat vraagt in theorie in meerdere opzichten om diepgaand onderzoek en het on-hold zetten van eventuele verdere publiek brede uitrol van vergelijkbare en andere digitale diensten.
De achtergrond met relatie van de adviseur tot de overheid is hierin prangend.
Het ministerie VWS kwam met het covid-19 gebeuren namelijk met het bureau KPMG in aanraking.
KPMG heeft nota bene het lerend vermogen van een organisatie als 1 van haar stokpaardjes gebombardeerd.
Dit nadat eerder zich schandaal op schandaal opstapelde waar ook de overheid in relaties bij betrokken was.
Dan moet je toch verwachten dat de overheid daarna zelf de stokpaardjes van haar adviseur(s) OOK snapt en op orde heeft.
Dus hoe goed werkt de radar om risico's in beeld te hebben bij het ministerie van VWS dan überhaupt?

Je moet tegelijk ook als kabinet en ook als tweede kamer grenzen kunnen stellen.
Als je top-risico uit eerder advies duidelijk niet goed in de smiezen is, dan heb je echt een mega probleem van Houston tot Tokio.

https://www.computable.nl/artikel/achtergrond/magazine/6266996/5215853/analyse-rijk-aan-icters.html
Gaat om ssc-campus, rivm zit daar samen met het knmi.
Niet iets waar de cultuur met direct contact naar burgers sterk is.

Waarom hebben ze geen aansluiting gemaakt met de olv app corona?
Daar lijkt het beter in elkaar te zitten. https://decoronacheck.nl

Als dit de standaardwerkwijze is dan verklaart dat veel.
https://magazines.rivm.nl/2017/09/campus-online/rekenen-met-het-modellenplatform-0 leveren van doosjes als technologie (Paas). De werkelijke software en applicaties en het gegevensbeheer voor de onderzoeker ofwel de gebruiker.

Politie waarschuwt voor rijks overheidssites die persoonlijke data aanbieden... zou ook niet miststaan als kop lo.

Werkelijk ongelofelijk die stupiditeit.

Op een web site die nog in ontwikkeling is met live data werken.

En dan nog lekken ook.

Ik kan tegen al die dommigheid niet meer op.

Ik heb al die ontwikkelaars in het verleden aldaar continu voor dit gedrag gewaarschuwd. Je wordt er zo moeeee van. O je het nou constructief aanpakt of niet... het heeft gewoon geen effect.

De overheid heeft nu wel de hoofdprijs gewonnen: Brevet van onvermogen.

Goede trol. Voor de rest van NL; dit was niet serieus...

Deze website draaide al sinds maart. Een enquete naar personen die de besmettingsgraad inschat. Het is niet de corona app waaraan nog gewerkt wordt. Wel degelijk al die tijd productie status met productiegegevens. Dacht je dat het virus in de werkelijkheid maar een fake iets was.

Ik zie eerder open source drupal php dictu als betrokken partijen.
Snel iets werkend krijgen tegen minimale kosten. Doe er een agile sprint sausje overheen en je hebt het klassieke probleem van gebrek aan kwaliteit.

Hoe hardleers kun je zijn. Uit [1]:
[1] https://tweakers.net/nieuws/168096/datalek-in-infectieradar-maakte-achterhalen-van-coronasymptomen-mogelijk.html
[2] https://tweakers.net/nieuws/165034/rivm-werkt-aan-nieuwe-versie-van-infectieradar-en-begint-onderzoek.html

Nee maar! Karma4 ziet open source als een betrokken partij! Die had ik nou helemaal niet zien aankomen!

Het gebrek aan kwailteit zit hem in de ontwikkelaars, niet in de software.
Software doet waar het voor geprogrammeerd is. Het is geen AI.
Als de otnwikkelaars steken laten vallen, dan is dat hun schuld. Niet die van de software.
Shit-in Shit-out (weet je wel)


Een hele domme vraag:
Heeft deze organisatie (of nog beter het Rijk) geen standaarden waaraan alle software en websites moeten voldoen.
En zit er in die standaarden geen beveilings-maatregelen die zit soort banale fouten hoort te voorkomen.

Zo nee, waarom niet,
Zo ja, waarom zijn die standaard-maatregelen dan (in dit geval) niet geimplementeerd.

Een keer bedenken en ontwikkelen. Meervoudig uitrollen. En zorgvuldig testen voor livegang, met een uitvoerig test-scenario.
Hoe moeilijk kan het zijn?

Wat leren die ontwikkelaars tegenwoordig op school.

https://www.artsenauto.nl/mexicaanse-griep/ Ik heb wel mijn bedenkingen bij sommige beslissingen, maar om achteraf te gaan zeggen dat je het van te voren allemaal wel wist is hoogmoed en arrogantie van de bovenste plank.
De politieke verwoording: "met de kennis van nu hadden we het toen anders gedaan"

Het verwijt toen, het bleek achteraf toch niet nodig geweest te zijn om in preventie te investeren. Een false positive
Het verwijt nu, de preventie en voorbereiding heeft gefaald er had meer preventie moeten zijn. Een false negative
Aangezien jij de toekomst zeker weet heb je zeker regelmatig je inkomen geregeld via hoofdprijzen in een loterij.

Jouw reactie zag ik wel aankomen, Het blinde geloof dat je met open source niets maar aan kwaliteit informatieveiligheid hoeft te doen. Het is de zelfde houding waarmee de NS zolang doorgegaan is met de fantastische Fyra, goedkoop en snel geleverd.
Pas toen er de platen afvielen bij het gebruik en herhaaldelijke uitval escaleerde het dat toch niet zo goed was.

Afijn, de links met de achterliggende organisaties, omvang en de verbanden heb je.
Met die kennis en kijkend naar het omvangrijke takenpakket wordt meer verklaarbaar zoals het verzamelde van de gegevens (onvoldoende openheid - correcties). Het gedoe met de corona-app en die appathon, het dashboard.
Het is hoe er gewerkt wordt .Met die kennis kun je verder om naar een oorzaak te gissen.

Die website "ïnfectieradar" moest zenld van de grond. Daar zit een CMS met database en een analyse database achter.
HTML kent geen definitie voor sessies transactioneel werken dat moet via het CMS komen. Nu kan zo's CMS nog meer, heet heeft functies voor formulieren. Duik ik daar in dan zie ik:
- session-ids 128 varchar, deze moeten random genoeg zijn maar zouden via een cookie in de browser kunnen lekken
Deze gaan niet via de url maar gebruiken de body.
- form-id daar komt een nummer via de url. (ia een get) Het cms doet de caching van de gegevens voor transactie logica
- De caches van het CMS wordt je geacht in beheer regelmatig op te schonen. Die uitspraak over het dagelijks schonen zie ik voor het moment als iets dubbelop ofwel non-informatie.

Wat is er nu mis gegaan? Het omgaan met de session-id heeft gefaald, de reden daarvoor is onduidelijk, het kan zijn:
- opdracht (vanuit management) om geen logon te gebruiken omdat je met users-www datatbase wel eens een datalek zou kunnen krijgen. Vervolgens is het opzetten van een sessie vergeten dan wel iedereen krijgt de zelfde sessie-id.
Het enige wat nog overblijft als je geen onderscheid in sessies hebt is dat formid met nummer naar een cache.
- Er zit een fout in het CMS dan wel webforms plugin deel waardoor het gebruik van sessie-id niet goed gaat.

Het werkt prima voor 1 gebruiker, een testen kan pas aantonen dat het niet goed gaat als hij minimaal twee aparte test accounts kan inzetten die volgens eis geen interactie mogen hebben. Testaccounts in het verlengde van service accounts. Zet daar tegenover de eis van snelle oplevering met agile sprints en je hebt een kwaliteitsuitdaging.
Het afdoen dat testen en kwaliteit niet nodig is omdat anderen wel de code gaan reviewen is zeer slecht.

Laten we maar blij zijn dat ze met de corona tracking app ingezien hebben dat specifieke inzet mensen van buiten noodzakelijk is. Het was beter geweest omdat niet ieder voor zich in Europa te doen. Alle ggd locaties in NL zijn in principe los staande organisaties daar is ook een overkoepelend iets..

Toen ik als tweejarige een eigen cms programmeerde in PHP maakte ik die fout niet eens!

Ah, dan ben je hooguit 23 jaar oud.

Een IDOR aanval is al zo oud, dat je je afvraagt hoe het überhaupt mogelijk was dat deze fout gemaakt is? Zelfs een amateur die websites bouwt, maakt zo'n fout niet eens!

En daar komt nog bij dat diezelfde overheid al eerder verschillende keren zwaar in de fout is gegaan met een IDOR-aaval. Het betrof toen - de nog niet geopenbaarde - Miljoenennota die voor het betreffende jaar gevonden kon worden door de cijfers in de URL van 2010 in 2011 te veranderen. Ook in het volgende jaar werd (weer) dezelfde IDOR fout gemaakt. Toen stond de Miljoenennota ook al online. En ook nu weer hoefde men 2011 in 2012 te veranderen. En net als je denkt dat diezelfde overheid die fout niet meer zal maken en ervan geleerd heeft, hoor je nu over een IDOR-aanval op infectieradar.nl.

Je weet het domme vragen bestaan niet, de richtlijnen zijn er.
- https://www.noraonline.nl/wiki/Authenticatie_in_de_praktijk (en de rest)
- https://www.ncsc.nl/documenten/publicaties/2019/mei/01/ict-beveiligingsrichtlijnen-voor-webapplicaties

Zelfs het proces wanneer en hoe je moet testen is er neergezet.
- https://www.noraonline.nl/wiki/ISOR:Systeem_acceptatietests
Let even op dat in het Agile gebeuren testen als vanouds niet echt aandacht heeft.
Het veilig ontwerpen zit er ook niet in.

- Snel goedkoop functionaliteit leveren is het dogma. Doe het Agile, waterval en eerste nadenken is fout.
- Als het niet kan zoals het moet doe het dan maar zoals het kan (tevredenheid klant)
- Als je open source gebruikt hoef je niet meer na te denken of veiligheid dan wel kwaliteit.

Als je er over nadenkt is hier is mis gegaan met de sessions rond het stateless zijn van html.
Een basaal nummertje als IDOR verwacht ik niet met de inzet van een CMS. Het zou kunnen als opdracht om de authenticatie te vermijden. In dat geval krijgt de ontwikkelaar het dubbel op zijn dak, die opdrachtgeven zal naar hem wijzen.

Lieve mensen,

Geef toch eens wat extra aandacht aan wat er allemaal gebeurt rondom de Corona-COVID19 hype, ook met het a.h.w. "uit de sokken" tracken van alles en iedereen.

Voorbeeld: Bombora Adtracking gevonden op threatstop dot com uit Phoenix, USA. Maar COVID-19 tracking komt ook hier en hoe. Ook de wrange vruchten zullen we er wel van plukken.

Het gebeurt dus allemaal met opzet en het dient een agenda die even iets verder reikt als uw en mijn gezondheid.
Een gewaarschuwd eindgebruiker telt dus voor twee. Maar weer luisteren er een heleboel mensen niet.
Net als, wanneer was dat ook al weer?

luntrus

Een zo eenvoudige beveiligingsfout in een applicatie laat je niet door het bedrijf herstellen die het gebouwd/geleverd heeft. Dan doe je er beter aan naar een nieuwe applicatie uit te kijken.

40 jaar geleden kreeg ik een gastcollege van een professor Herzberg of Herzberger over computerbeveiliging. Zijn stelling was:
"... Beveiliging is de basis waarop je een applicatie bouwt. Wanneer je denkt dat je beveiliging achteraf nog kunt toevoegen of verbeteren maak je een grote denkfout. Dat is als geblinddoekt alle gaten in een vergiet dichten met propjes brooddeeg ..."

Ik heb zelf een keer een cruciale applicatie van de Rijksoverheid gehackt (white hat); en het is waar. De bouwer waarmee ik professioneel contact had probeerde het lek te dichten, maar ik wist steeds sneller een nieuw gat te vinden. Pas nadat er op het niveau van het operating system nieuwe beveiligingsmethoden werden aangeboden was de beveiliging weer sluitend; het fundament was hersteld. De toegevoegde beveiligingsmaatregelen in de applicatie waren daarna zelfs overbodig.

Zelfs al hadden ze het nummer niet in de URL query string gezet (zichtbaar in de meeste browsers) en in plaats daarvan geprobeerd te 'verbergen' in een http request header (niet standaard zichtbaar in de gangbare browsers), dan nog is het voor een gemiddelde nerd even makkelijk om te hacken.
F12 + Postman.

Ik weet niet wie de leverancier is maar Infectieradar is onderdeel van Influenzanet, een Europees samenwerkingsverband tussen verschillende universiteiten en overheden. Even snel iets aanpassen moet je dus wel nog goed testen. Dat hebben ze blijkbaar overgeslagen in de haast en haastige spoed is zelden goed. Vervolgens kunnen de zelfverklaarde security mannen weer los op security.nl

Dat is ook apart. De ontwikkelaar had een vooruitziende blik terwijl windows continue ernstig lek is volgens Microsoft patch Thuesday.

Zodra er blijkt fouten ingebakken te zijn in een set (van instructies, de software) dan heeft het geen zin om de fouten 1 voor 1 langs te lopen, dan is je set fundamenteel instabiel.
De hele set niet opnieuw opbouwen is zo ongeveer nog erger dan fouten in 1 dragend deel van gebouw projecten niet willen herkennen en oplossen.
De set van instructies is namelijk de gehele drager voor het bouw pakket.
Wat daar in ingebakken zit, zit dan potentieel ook door het hele bouw-pakket.

Voor dit soort problemen hoef je niet te testen. Als ontwikkelaar behoor je te weten dat je een lek aan het programmeren bent.

Wat dat betreft heeft Erik gelijk. Je kunt dit programma beter vanaf scratch opnieuw laten schrijven. De huidige schrijver(s) doe zo'n inkopper niet ziet, kan er nog veel meer lekken in achtergelaten hebben.


Dat heeft toch een iets andere nuance. Daar ging het om informatie waarvan het al de bedoeling was om openbaar te maken. Om het heel getimed op te minuut nauwkeurig te publiceren hebben ze de keuze gemaakt om het grootste deel al op de uiteindelijke plek te zetten, zodat ze alleen het linkje hoefden te plaatsen op het moment dat de miljoenennota gepresenteerd werd. Het had beter gekund met een hash in de link, maar misschien wilden ze een link gebruiken waarmee je ook simpel oude mljoenen notas kon opvragen. (In elk geval vind ik dit soort linkjes, zonder hashes, handig om oude verslagen op te vragen)

Ik begrijp je opmerking niet. Het onderliggende besturingssysteem was een mainframe OS van IBM. In die tijd zover ik me kan herinneren MVS/ESA of OS390

Dat lijkt op de tijd dat je met SAF calls de security uit de applicaties naar buiten bracht RACF ACF2 waardoor alles structureel veel beter te beveiligen is. Het is iets wat bij Unix Linux ontbreekt en bij AD door Cutler is ingebracht in NT het einde van OS/2.

De zelfverklaarde securityspecialisten dien enkel met een OS flaming bezig wensen te zijn hebben daar geen boodschap aan.

Ik zit nog met de vraag van het ontbreken van sessiemanagment rond html en specifiek die RIVM benadering.
Als alles onder een enkele identiteit identiek service account draait dan heb je een fundamenteel probleem.
Zit dat in het CMS fout dat is het veel ernstiger als het enkel deze RIVM website is.

Heb je nog keuze om de app te instaleren?? Op Android, als je in de instellingen de zoekfunctie gebruikt en zoekt naar Covid... Dan zie je dat je telefoon al klaar is om gegevens te delen! Ook al heb je 4 maanden geen updates meer gedraaid!!!

Smeerlappen zijn het!

99,99% van de security verrassingen komen niet hier vandaan. Maar juist in andere delen van het OS.
Verder zijn er niet zoveel issues rond deze niet-implementatie. Dus wat is precies je punt ?

@Karma4 Overigens doe je zelf vrolijk mee aan het OS wellus-nietus gedeelte. Meestal met 110% inzet.

Een keer kan een verschrijving zijn, maar na een tweede keer reageer ik toch maar. Sessies zijn helemaal niet van toepassing bij HTML, want dat is een paginabeschrijvingstaal die daar los van staat. Sessies gaan over het aan elkaar knopen van verschillende interacties en dan heb je het over wat op het niveau van het communicatieprotocol gebeurt, dus HTTP en HTTPS. HTTP cookies worden sinds 1995 toegepast, ook voor sessiebeheer. Dit probleem is al een kwart eeuw geleden opgelost.
Dat gaat niet over sessiestaat maar over het ophalen van gegevens met een URL-parameter zonder enige toegangscontrole, ongeacht in welke sessie dat plaatsvindt. Een uniek deelnemernummer identificeert een persoon, niet een sessie. Dat is niet hetzelfde.
Niet het probleem waar je het nu over hebt, dit zit weer op een ander niveau.

Je haalt behoorlijk wat zaken door elkaar.

Het moest haast wel een fout zijn. Jullie denken toch niet dat hier iets achter zit, zat?
Er deed zich even een gedachtenrimpeling voor in mijn onderhavige brein.
Zag je die korte curve in het algorithme?

Maar wie zet hier dit soort "klutsers" dan aan het werk?
Zo iemand kan geen nieuw lid van een cyber-bevlogen "blue team" zijn, toch?
Een dergelijk iemand heeft weinig kennis (noch veel ervaring), maar wel torenhoge aspiraties vaak.

Dat past beslist bij deze development-situatie en de uitdaging (localisatie-surveillance onder mom van dreiging);

Immers de echte white hat researcher is doorgaans niet arrogant en "neuswijs".
En een echte tech-bevlogene wil nooit een plekje tussen dat soort van "muikerds".

Jodocus Oyevaer

HTML is inderdaad stateless. Je moet het via trucs (cookies) en sessie informatie oplossen om transacties aan te kunnen.
Een transactie gaat als volgt:
- inloggen - aanmaak sessie https://www.drupal.org/project/session_api
- Tonen in te vullen formulier https://www.drupal.org/docs/8/api/form-api/introduction-to-form-api
- Controleren in te vullen forrnulier met een cache zodat verbeteringen op het scherm aangebracht kunnen worden
- Na controle en bevestiging opslaan van het formulier
- Met het uitloggen of na een timeout opschonen van de sessie gegevens.
Heb je opgemerkt dat de formulieren in het CMS genummerd worden. Moet wel, anders is die cache niet te doen.
Dat nummertje komt ook in de url terug als zo wat rondkijk.

Een sessie hoort de persoon vanaf begin tot eind in de browser en op de server afgescheiden van de rest te houden.
Ontbreekt de sessiekoppeling de sessieafscherming dan hou je dat enkel URL gebeuren over, het basale niet beveiligde HTML gebeuren.

Niet door elkaar gehaald, enkel naar het probleem geluisterd en bedenken wat er aan de hand kan zijn.
Een ICT-er moet luisteren en de analyse met interpretatie doen. Wat gezegd wordt is/hoeft niet de werkelijke situatie te zijn. De kennis hoe techniek aan elkaar hangt is een voorwaarde.

De termen stateless en statefull slaan op communicatieprotocollen. HTML is geen communicatieprotocol maar een paginabeschrijvingstaal. Ik heb het al uitgelegd: het communicatieprotocol is hier HTTP of HTTPS. Dat is inderdaad stateless, maar dat is, zoals ik al meldde, 25 jaar geleden al ondervangen door cookies toe te voegen. Die worden via HTTP-headers gecommuniceerd, buiten de HTML om.

Kan wezen, maar het nummertje in de URL waar het nu over gaat is iets anders, een deelnemernummer. De sessiecookie, het formuliernummer en het deelnemernummer zijn drie verschillende dingen. De sessiecookie wordt via HTTP-headers geregeld, niet via URL-parameters. Voor het aansturen van caching zijn er ook HTTP-headers.

Alleen ontbreekt de sessiekoppeling niet, dat is iets dat door werkelijk elk webframework en CMS keurig wordt ondersteund. Je redeneert alles toe naar iets dat hier helemaal niet aan de orde is.

Knap hoor. Maar vervolgens is ook nodig dat je voldoende van de techniek begrijpt om te kunnen verifiëren of wat je bedenkt klopt. Daar schort het duidelijk aan, je wordt erop gewezen dat je dingen door elkaar haalt en in plaats van daar iets van te leren zet je je hakken in de grond en ga je volhouden dat je misvattingen de waarheid zijn.
Klopt helemaal. Je past het alleen niet toe, je maakt jezelf alleen maar wijs dat je het doet.

SAF werd bij ons niet of nauwelijks gebruikt. Alles was gescheiden adhv users met specifieke bevoegdheden en bestandsnamen die qua opbouw bij test dan wel productie behoorden. Applicaties bevatten bij ons geen security gerelateerde code.

Ik geloof wel dat SAF op een gegeven moment gebruikt werd om DB2 resources op uitvoeringstijd te koppelen aan de voor die omgeving specifiek database-omgevingen.ACF2 was bij ons al in gebruik.

De hack betrof simpel de debug mogelijkheden van ISPF-PDF waarbij breekpunten gezet konden worden en variabelen gemanipuleerd. Het betrof een zelf gebouwd applicatie management/archief systeem dat ook in de TSO-omgeving moest functioneren.

De toevoegingen die het systeem weer dicht maakten waren ACF2-configuratieparameters waarmee specifiek exec-librarysources en dd-names benoemd konden worden als geautoriseerd voor manipulatie van specifieke datasources.

De leverancier van de software heeft inmiddels een oplossing doorgevoerd. Deze oplossing wordt nu door het RIVM en een externe partij getest. Zodra we zeker weten dat de vragenlijsten veilig worden opgeslagen, gaan het RIVM verder met de Infectieradar.

Geen misbruik datalek Infectieradar
Publicatiedatum 08-06-2020 | 16:27

https://www.rivm.nl/nieuws/geen-misbruik-datalek-infectieradar

Net zoals iedere andere software, wat op een ieder willekeurig moment een seurity update kan uitbrengen.

Het is software van de overheid, natuurlijk kan je dat verwachten! Ik vind het schokkend dat het nu pas gemeld wordt, maar ook dat is eigenlijk niet anders dan verwacht...