Accountants konden aangiften oud-cliënten inzien door fout Belastingdienst

Door een fout bij digitale DigiD-machtigingen, waardoor ieder voor een ander belastingaangifte kan doen, konden sinds vorig jaar onder meer accountants de persoonsgegevens en aangiften van oud-cliënten inzien en aanpassen, ook al was daar geen toestemming voor.

De Volkskrant meldt dat het afgeven van deze machtiging, waardoor bijvoorbeeld accountants inzage krijgen in het persoonlijke DigiD van cliënten, maandenlang niet in orde was. De krant had contact met een accountant uit Rotterdam die het datalek bij toeval ontdekte: "Toen ik in november vorig jaar met de aangiftes van twee klanten bezig was, zag ik de naam van de één rechtsboven in mijn browser staan, terwijl ik in de gegevens van de ander zat." Hij bleek toegang te kunnen krijgen tot de persoonlijke gegevens van een voormalige cliënt die voor 2018 geen machtiging meer had afgegeven.

Deze ongeoorloofde toegang was mogelijk door eerst in te loggen en gebruik te maken van de machtiging van een andere cliënt. Door in de Edge-browser op de terug-knop te klikken belandde de accountant bij een lijst met verschillende cliënten, waaronder ook enkelen waarvan de machtiging al was verlopen. Hij kon bijvoorbeeld uitroeptekens zien bij oud-cliënten, wat betekende dat zij nog aangifte moesten doen. "Als ik kwaad zou willen, zou ik dus de aangiften waar ik geen toegang tot mag hebben, kunnen aanpassen. Hoe dan ook is het natuurlijk niet de bedoeling dat ik toegang tot die strikt persoonlijke informatie heb", aldus de accountant. In feite was de lopende machtiging van een enkele cliënt genoeg om ook toegang te hebben tot de gegevens van andere cliënten.

De Belastingdienst heeft de fout erkend en het datalek gemeld bij de Autoriteit Persoonsgegevens. De overheidsdienst zou de fout deze week hersteld hebben. Dat betekent dat onbevoegden in ieder geval ruim een half jaar toegang hadden tot de persoonlijke gegevens van personen die eerder een machtiging hebben afgegeven voor de belastingaangifte. Het is niet duidelijk hoeveel mensen hierdoor getroffen zijn en of er sprake is geweest van misbruik. De Belastingdienst laat weten dat meerdere browsers worden getest, maar dat deze fout nooit eerder boven water is gekomen. Bij andere browsers dan Edge speelde dit probleem niet; er volgde een foutmelding als de terug-knop werd gebruikt.

Reacties (64)

[BikkelZ]

Wel gek om zo'n rijtje ergens in de browser historie weg te schrijven. Maar je kunt wel raden wie nooit meer in zijn leven alleen in Chrome test

[Gamebuster]

Mijn aanname hier is dat door het gebruik van "vorige" er (API) requests uit cache werden opgehaald, of misschien zelfs uit data opgeslagen in de browser. In deze cache stond een referentie naar een verlopen machtiging, maar de server controleert niet of een machtiging verlopen is bij het ophalen van de data.

[Elephtera]

Ze testen wel in diverse browsers. Net als bij andere bedrijven. Maar wat hier meespeelt is dat ze binnen de belastingdienst helemaal geen edge hebben omdat ze op Windows 8.1 draaien.
En bij andere bedrijven die je dat niemand edge gebruikt, en de testers en ontwikkelaars Chrome Firefox en safari testen maar niet stilstaan bij ie of edge want wie gebruikt die "rotzooi" nou nog.
Nou, ik gebruik die rotzooi en heb zo bij eigenlijk elk bedrijf issues gevonden die enkel in edge voorkwamen.

[Zoop]

Als je praat over dit soort dingen, dan mag het hooguit over specifieke html/css/javascript gaan, clientside dingen dus. Dat die nog wel eens verschillende resultaten geven in verschillende browsers is al een decennia oud probleem, maar wezenlijk mag dat geen zak uit maken. Dat zijn hooguit problemen in de presentatie, user interface dingen enzo.
Absoluut geen authenticatie dingen! Dat mag nooit afhankelijk zijn van de browser. Dat moet allemaal aan de serverkant gebeuren, en dan moet het dus niet uitmaken wat voor soort browser je gebruikt of dat de daardoor bugged.
Alles aan de client kant valt te manipuleren, als een Edge "per ongeluk" toegang geeft, dan kan je dat vast wel in iedere browser voor elkaar krijgen als je in de inspector gaat klooien.
Dus dit is geen probleem door gebrek aan testen in Edge ofzo, probleem zit aan de serverkant, en die is veel ernstiger.

Kortom, dit is buitengewoon knullig.

[Anoniem: 710428]

Dat speelt niet mee want de ontwikkelaars testen ook gewoon op Windows 10 met Edge, omdat de impact niet alleen de medewerkers van de belastingdienst zijn, maar het hele land.

[TheMak]

Het is alleen een beetje lastig vooraf te testen. Een testscenario zou zijn, het systeem voor jaar 2019 inrichten. Accountant permissie geven. En dan alle systemen een jaar (naar 2020) vooruitspoelen (client, webserver, backend servers) de systemen inrichten met de belastingformulieren die nog niet bestaan. Toestemming intrekken en dan kijken of de accountant bij de nieuwe gegevens kan. Waarschijnlijk moet de accountant nog wel bij de oude gegevens kunnen.

[Groningerkoek]

Als een machtiging word ingetrokken mag de accountant ook niet meer via de belastingdienst bij de oude gegevens kunnen. Tevens moeten machtigingen voor elk belastingjaar afzonderlijk worden doorgegeven.

[hackerhater]

Daar heb je behaviour tests voor samen met test datasets

[supersnathan94]

Daar is niks lastigs aan. Je kunt dit orima in een test environment zo modelleren en behaviour testing doen.

Iets simpels als een api call met een oud machtigings ID zou in je standaard regressie testen moeten zitten.

[RJG-223]

Dit heeft niets te maken met testen op een bepaalde browser. Dit is een probleem van blijkbaar slecht opgeleide ontwikkelaars, en/of een incompetente ontwikkel-organisatie, die onvoldoende kennis hebben van adequaat beveiligen van toegang tot persoonlijke gegevens via een website.

Edit: het kan natuurlijk ook zijn dat de belastingdienst incompetent is in het selecteren van een website-ontwikkelaar met de juiste kennis en ervaring om zo een website te maken. Of dat waarschijnlijker is weet ik niet. Als ze met groot bedrijf in zee zijn gegaan, dan kun je het dat bedrijf sowieso verwijten.

[Reactie gewijzigd door RJG-223 op 23 juli 2024 07:44]

[Vizzie]

Elke win 10 installatie heeft toch edge?

Dus het wordt mogelijk op elke nieuwe pc van de laatste paar jaar gebruikt.

Dat een ontwikkelaar zich niet op edge richt is tot daar aan toe (ook niet echt ok) maar professionele testers laten edge echt niet links liggen bij het testen (hoewel ze hier blijkbaar toch een enorme steek hebben laten vallen).

[Elephtera]

De belastingdienst zit nog op windows 8.1, geen enkele pc daar heeft windows 10, en al helemaal niet de developers/testers.
Dus zelfs al zouden ze het willen testen met edge, ze kunnen het niet en zijn aangewezen op IE11, Firefox en (kale)chrome. Er is geen mogelijkheid om zelf software te installeren.
Dit alles met als doel beveiliging en controle.

[Vizzie]

Het lijkt mij tamelijk onbestaanbaar dat een organisatie als de belastingdienst professionele (externe?) testers geen mogelijkheden geeft om met een ander platform dan win 8.1 met Firefox en Chrome te testen.

[batjes]

Prima mogelijk
https://developer.microso...microsoft-edge/tools/vms/
Edge draait overal.

[HeelErgEdwin]

Het is nog absurder dat als je de link hebt naar een aangifte deze gewoon werkt.
Op het moment dat je op de link klikt moet de server ‘nee’ zeggen.

[Damic]

De nieuwe Edge is op Chromium gebaseerd, gelukkig steken ze er wen een IE-backwards test deel in

[D-Three]

De Belastingdienst laat weten dat meerdere browsers worden getest, maar dat deze fout nooit eerder boven water is gekomen. Bij andere browsers dan Edge speelde dit probleem niet; er volgde een foutmelding als de terug-knop werd gebruikt.

Zoiets mag toch totaal niet af hangen van welke browser je gebruikt?

[Reactie gewijzigd door D-Three op 23 juli 2024 07:44]

[Praetextatus]

Nou vrijwel elke browser werkt toch anders en heb zulke browser issues vaker gezien. Er is simpel weinig niet genoeg tijd uitgetrokken om goed te testen.

Edit, geen idee waarom ik een - 1 krijg eigenlijk. Volgens mij is dit gewoon on topic en geen ongewenste reactie?

[Reactie gewijzigd door Praetextatus op 23 juli 2024 07:44]

[frickY]

Het is een probleem met de software op de server.
Dat die bug zich in de ene browser wel of makkelijker manifesteert dan in de andere doet daar niets aan af.

[Gamebuster]

Je krijgt een -1 omdat je reactie misleidend is.

Dergelijke issues op de server afgevangen moeten worden en dit dus totaal onafhankelijk van de browser zou moeten zijn. "Don't trust user input" (note: De browser en de keuze voor een browser is user-input)

[Reactie gewijzigd door Gamebuster op 23 juli 2024 07:44]

[kakanox]

Misleidend is dat zeker niet; dat is alleen van toepassing wanneer je ervan uit gaat dat een andere Tweaker dezelfde kennis heeft als jij, of je reacties van Tweakers leest alsof ze allemaal de volledige waarheid in pacht hebben.
Als je onvoldoende inzicht hebt in hoe authorisatie in elkaar moet zitten is het bericht van @Praetextatus een volstrekt logische reactie, en een hele mooie kans voor andere Tweakers om dat eens netjes uit te leggen.

Bijvoorbeeld zoals @Keypunchie ook gedaan heeft.

[Praetextatus]

Ik ben wel benieuwd waar de misleiding dan nu in zit?
1. Elke browser werkt anders namelijk, ook al hebben ze overlappende code
2. Ik heb nergens beweerd dat het niet op de server afgevangen moet worden
3. Als ze genoeg tijd hadden genomen, hadden ze beter kunnen testen.

Dus waar is de misleiding precies? Volgens mij allemaal on topic.

[Gamebuster]

Ik begin met je originele quote:

Nou vrijwel elke browser werkt toch anders en heb zulke browser issues vaker gezien.

Het is geen browser-issue, het is een server issue.

Dat de gebruiker verlopen records kon inzien betekent dus dat er geen serverside controle was op de start- en/of eindtijd van een machtiging.

Reacties op je 1-2-3:

1) Het heeft helemaal niets met de browser te maken, behalve dat de gebruiker er nu toevallig achter kwam omdat de browser referenties naar het verlopen record in cache had (o.i.d., whatever). Het maakt niet uit hoe een browser werkt, dit mag niet gebeuren.
2) Je hebt wel beweerd dat het een browser-issue is, wat onwaar is. Zie 1. Je kan hooguit beweren dat het gebruiken van de terug-knop oude data laat zien, wat wellicht een browser issue is, maar dat is het probleem niet. Het probleem is dat de server de verzoeken accepteert o.b.v. oude data opgeslagen in een browser. Deze "verouderde data" kan natuurlijk ook zelf gefabriceerd worden door een handig persoon (wat zo makkelijk kan zijn als een paar cijfertjes veranderen). Hier komt geen browser bij kijken.
3) Zeker. Moeten ze natuurlijk wel op server niveau al gaan testen.

Door het af te schuiven op Edge / browser issue kunnen lezers de indruk krijgen dat het hier gaat om een bug uit de browser, maar het primaire probleem is gebrekkige beveiliging van de belastingdienst's software. Daarom gaf ik aan dat je reactie misleidend is.

Lang verhaal kort: frickY in 'nieuws: Accountants konden aangiften oud-cliënten inzien door fout...

[Reactie gewijzigd door Gamebuster op 23 juli 2024 07:44]

[Praetextatus]

Ik begin met je originele quote:


[...]

Het is geen browser-issue, het is een server issue.

Dat de gebruiker verlopen records kon inzien betekent dus dat er geen serverside controle was op de start- en/of eindtijd van een machtiging.

Waarom gaat het dan bij andere browsers wel goed?

Door het af te schuiven op Edge / browser issue kunnen lezers de indruk krijgen dat het hier gaat om een bug uit de browser, maar het primaire probleem is gebrekkige beveiliging van de belastingdienst's software. Daarom gaf ik aan dat je reactie misleidend is.

Ik begrijp niet waarom je denkt dat ik een persoonlijke aanval op Edge doe en daarop afschuif. Zoals ik al aangaf, goed test werk had dit moeten vinden. Het probleem ligt, zoals meestal, aan strakke deadlines en daarop wordt het meeste bezuinigt op test werkzaamheden.

[Keypunchie]

Waarom gaat het dan bij andere browsers wel goed?

Omdat die zich netjes gedragen.

Stel je hebt een kantoor. Bezoekers melden zich aan de balie en daar kijkt een receptionist met wie ze een afspraak hebben. Hebben ze geen afspraak stuurt hij ze weg, hebben ze wel een afspraak dan doet hij de deur open.

Nu komt 'Edge' binnenlopen en roept "ik heb een afspraak hoor", de receptionist doet zonder te contoleren de deur open en 'Edge' loopt zo door. Is het relevant waarom het "wel goed" gaat met de andere bezoekers? Nee, je beveiliging is gewoon niet op orde. Die deur hoort dicht te blijven.

@MN-Power Analogieën zijn nooit perfect. Maar volgens mij vinden we allebei hetzelfde. Dit is geen ‘probleem’ met Edge, maar server-side.

[Reactie gewijzigd door Keypunchie op 23 juli 2024 07:44]

[MN-Power]

Die browser kan nooit iets tonen wat niet door de server aangeleverd wordt. De fout ligt dus bij de server en niet bij de browser. Die hoort alleen de gegevens terug te geven die op het inlogmoment geldig zijn, en niet de hele historie en dan client side filteren. Is nog inefficiënt qua dataoverdracht ook, zeker bij de grote accountantskantoren.

Het is dus niet Edge die zich niet gedraagt. Oftewel in jouw voorbeeld ligt het hele klantenbestand open en bloot bij de receptie. Je kan het alleen niet zien als je je ogen dicht doet

[Reactie gewijzigd door MN-Power op 23 juli 2024 07:44]

[polthemol]

dat het bij andere browsers goed gaat is niet relevant De code op de server (hoe die certificaten/machtigingen controleert) werkt niet zoals het hoort. Je hebt nu immers de situatie dat het machtigingensysteem anders werkt voor me als ik een andere browser gebruik (oftewel: ik kan actief sturen op hoe die machtiging voor mij werkt afhankelijk van welke browser ik gebruik, dat is raar ).

De server zou geen verschil mogen maken op het punt van machtigingen/security met welke browser er in gebruik is, dat zijn stukjes van je proces wat je absoluut gescheiden moet houden.

[Praetextatus]

dat het bij andere browsers goed gaat is niet relevant De code op de server (hoe die certificaten/machtigingen controleert) werkt niet zoals het hoort. Je hebt nu immers de situatie dat het machtigingensysteem anders werkt voor me als ik een andere browser gebruik (oftewel: ik kan actief sturen op hoe die machtiging voor mij werkt afhankelijk van welke browser ik gebruik, dat is raar ).

De server zou geen verschil mogen maken op het punt van machtigingen/security met welke browser er in gebruik is, dat zijn stukjes van je proces wat je absoluut gescheiden moet houden.

[...]

Omdat die zich netjes gedragen.

Stel je hebt een kantoor. Bezoekers melden zich aan de balie en daar kijkt een receptionist met wie ze een afspraak hebben. Hebben ze geen afspraak stuurt hij ze weg, hebben ze wel een afspraak dan doet hij de deur open.

Nu komt 'Edge' binnenlopen en roept "ik heb een afspraak hoor", de receptionist doet zonder te contoleren de deur open en 'Edge' loopt zo door. Is het relevant waarom het "wel goed" gaat met de andere bezoekers? Nee, je beveiliging is gewoon niet op orde. Die deur hoort dicht te blijven.

Dank voor de heldere uitleg!

[Praetextatus]

misleiding v

een opzettelijke en geslaagde poging iemand een onjuiste indruk te geven

Verwante begrippen
bedriegerij, bedrog


Nee ik heb toch niemand misleid gelukkig

[Gamebuster]

Hah oke vooruit

[TheVivaldi]

Maar dan 0 je zijn i.p.v. -1. Even nadenken, volgende keer.

[D-Three]

Maar in dit specifieke geval zou het niet mogen uit maken. Zelf al zit er nog een oude link in de cache van de browser of wat dan ook, geen toegang zou geen toegang moeten zijn. Het lijkt mij dat in dit geval de server niet keek of de gebruiker wel recht had op toegang tot de specifieke data of enkel bij het inloggen. Ik ben geen webdev maar de laatste zin in het artikel laat bij mij toch een alarmbel rinkelen.

[Reactie gewijzigd door D-Three op 23 juli 2024 07:44]

[White Feather]

Het is inderdaad van de zotte dat ze dit als excuus aangeven. En wat hadden ze gedaan als ze het in Edge hadden getest en wèl gevonden? Een specifieke functie gemaakt voor Edge om te voorkomen dat een pagina terug werkt?

Dan kun je daarna zeggen dat alles veilig is zeker, want we zien niets meer fout gaan.

Dit moet natuurlijk gewoon op de server zelf geregeld worden. Dan weet je gewoon dat het in geen enkele browser fout kan gaan.

[Keypunchie]

Omdat je autorisatie van gegevens *nooit* aan de cliënt mag overlaten.

Beetje denken alsof je een pagina kunt beveiligen door de rechter-muisknop-actie af te vangen. Als het in 1 browser misgaat, kan het ook in andere browsers misbruikt worden, door een extensie of scriptje.

[emnich]

Dit inderdaad. De server besluit welke gegevens verstuurd worden en daar gaat het fout.

Als je het laat afhangen van een browser heb je geen idee waar je mee bezig bent.

[Splorky]

De toegang zal vast niet door de browser bepaald worden (zou wel heel erg slecht zijn).

In Jip en Janneke taal van mijn gok:
Ik vermoed dat er een security token wordt aangemaakt bij het voor het eerst inloggen in het account van de client door de accountant. daarna wordt alleen gekeken of de token nog geldig is (als in verval datum)

Als op een later moment de machtiging wordt ingetrokken dan kan er geen token meer gegenereerd worden maar oude tokens worden door dat systeem niet ingetrokken en kunnen gebruikt blijven worden.

Ik vraag me af of dit specifiek voor Edge werkt want andere browsers worden niet uitgesloten.

[emnich]

Je doet nu alsof het een race condition is maar zoals ik het begrijp gaat het niet specifiek om klanten die net de machtiging ingetrokken hebben maar al veel langer geleden.

Het probleem is dat er werd beveiligd op basis wat een client kon doen ipv wat een hacker zou doen.

Je test dus niet alleen de beveiliging van de urls die je aanbiedt maar juist ook die van de urls die je niet aanbiedt

[Amiga3000]

Inderdaad dit is gewoon een slecht design van een webapp, prutsers..

[RJG-223]

Als op een later moment de machtiging wordt ingetrokken dan kan er geen token meer gegenereerd worden maar oude tokens worden door dat systeem niet ingetrokken en kunnen gebruikt blijven worden.

Ik dacht dat je het had over tokens met een vervaldatum ? Hoe ver in de toekomst mag die vervaldatum dan liggen volgens jou ? Het gaat (zo ik begrijp) om gegevens van oud-clienten die al minstens 9 tot 11 maanden geen klant meer waren (want we hebben het over november 2018, er er was voor 2018 geen machtiging afgegeven). In dit soort gevallen met gevoelige informatie (we hebben het niet over een token voor een eenvoudige website als tweakers.net!) moet een autorisatie-token na een aantal minuten van inactiviteit, of hooguit aan het einde van een dag, verlopen.

Het lijkt er dus op dat in dit geval de toegang tot het account van een cliënt wel (deels) bepaald werd door gegevens die van de browser afkomstig waren, en dat de veiligheid erop gebaseerd was dat de accountant het account van een oud-client niet kon selecteren in zijn browser. De toegang werd in ieder geval niet bepaald door een client-specifiek token met een geldigheid van maximaal een dag !

[MrMonkE]

Je moet je tokens serverside invalideren.. easy peasy.
Om een voorbeeld te noemen: Als iemand zijn wachtwoord wijzigt of uitlogt.

Tweakers laat je zelfs kiezen als je uitlogd welke sessies je wilt killen.


Ik moest gewoon hardop lachen, zelfs aanpassen is/was mogelijk

[Reactie gewijzigd door MrMonkE op 23 juli 2024 07:44]

[locke960]

Ik vermoed een fundamenteler probleem dan die tokens. Het lijkt er op dat de gebruiker zich bij de applicatie op de webserver aanmeld, maar dat de applicatie zelf altijd volledige toegang heeft tot de database, en dat de applicatie beslist wat de gebruiker wel of niet te zien krijgt en mag doen.
De applicatie, die natuurlijk continue aangepast wordt en dus zeer gevoelig is voor bugs, is zo ook verantwoordelijk voor de gegevensbescherming.
Het moet natuurlijk zo zijn dat de database zelf toegangscontroles doet, onafhankelijk van de applicatie, net zoals filesystemen doen.

Of het echt zo is weet ik natuurlijk niet, maar het lijkt er wel op.

[Groningerkoek]

Ik zeg niet dat je ongelijk hebt, maar ondanks het gepruts bij de overheid met ICT kan ik mij niet voorstellen dat zo'n keuze is gemaakt, de cliënt laten bepalen wat hij wel of niet mag zien zou wat mij betreft gewoon een strafbaar feit moeten zijn, dit zou de deur te gemakkelijk wagenwijd openzetten voor grootschalig misbruik.

[Left]

Ik probeer je gedachtengang te volgen; bedoel je dat een security token dat werd aangemaakt voor het inloggen bij een bepaalde klant, ook toegang gaf tot andere klanten? Dat lijkt me een nog veel grovere fout.

IMO is het duidelijk dat de belastingdienst een deel van de autorisatie in de browser zelf heeft geimplementeerd. Dat lijkt mij de enige verklaring waarom Edge dit probleem wel heeft en andere browsers niet.

[Iblies]

[...]

Zoiets mag toch totaal niet af hangen van welke browser je gebruikt?

Dit lijkt me dus ook een leugentje om bestwil.

Geloof namelijk niet dat bij Edge is getest wanneer iemand een browser weg klikt, dat daarna gecontroleerd is of je weer bij oude gegevens kunt komen dmv history.

Het hoe en waarom zal ook waarschijnlijk een raadsel blijven omdat de algemene kennis van de managers maar ook de minister zelf simpelweg te weinig is om details toe te lichten en hier dieper op in te gaan.
Er wordt nu een pleister opgeplakt, maar ik geloof niet dat er meer structurele oplossingen gaan komen. Nu Microsoft heeft besloten om als basis ook chromium te gebruiken, en Firefox langzaam ook een nieuwe engine zal er binnen enkele jaren weer een deja-vu komen.

[psychodude]

Ik ben dan ook zeer benieuwd hoe ze dit probleem hebben opgelost, cliënt side enkel de bug met edge verholpen? Dan persisteert het probleem nog altijd.

[0xygen500]

Stel je meldt dit bij AP wat wordt er dan mee gedaan? AP weet al dat Belastingdienst zijn zaakjes nog niet op orde heeft. Wordt dit dan gewoon geaccepteerd?

[dez11de]

Ze hebben speciaal voor dit soort vragen een pagina gemaakt. https://www.autoriteitper...financien/belastingdienst

[Trommelrem]

Ach, de belastingdienst heeft in ieder geval goede auditing, dus ze kunnen precies achterhalen welke sofinummers zijn ingezien door welke accountants. De melding naar de belanghebbenden zal misschien vandaag nog worden verstuurd

[Reactie gewijzigd door Trommelrem op 23 juli 2024 07:44]

[HeelErgEdwin]

De Facebook pagina van de belastingdienst meldde dat er niet wordt gewerkt tot en met zondag. Dus dat zal wel volgende week ergens worden (sinds wanneer is de dag na Hemelvaart een feestdag?)

[ATS]

Het is geen feestdag, maar als een heel groot deel van je personeel die dag vrij wil nemen om een lang weekend te creeëren, dan is het soms handiger om dan maar te besluiten dat het voor iedereen een verplichte vrije dag is.

[mar-10]

Dat noemen ze binnen de overheid een blokdag, wat een door de werkgever aangewezen feestdag is. De dag na hemelvaart en/of dagen tussen kerst en weekend worden vaak aangewezen. Veel personeel neemt sowieso vrij en mensen gaan juist op vrije dagen achterstallige zaken inhalen, dus komt de externe dienstverlenging bij de overheid door lage bezetting en hoge vraag in de knel. Oplossing: geen dienstverlening
(let op: dit is een beetje gechargeerd)

[Trommelrem]

Melding AVG moet binnen een x aantal dagen, niet werkdagen.

[Groningerkoek]

72 uur staat hiervoor.

[Splorky]

Zou ze sieren om die gegevens online inzichtelijk te maken.

misschien anders dat je dit per brief formulier met toevoeging van ID kan aanvragen en dat je binnen 8 weken een reactie krijgt?

[FrankHe]

Dit is voor mijn gevoel gewoon en keiharde ontwerpfout van de laag die de machtigingen beheert. Heeft niets te maken met wat de web browser doet. En heeft er alles mee te maken hoe het systeem server side kennelijk niet goed is ontworpen en of gebouwd. Waarschijnlijk wel netjes alle unit tests gedaan maar de regressietest niet of niet volledig uitgevoerd. Dit issue had bij het testen naar voren moeten komen en eigenlijk in een veel eerder stadium al op de tekentafel voor vragen moeten zorgen.

[Falcon]

Unittesten en API/Service testen inderdaad.

[sympa]

Eerder een kwestie van een goed ontwerp. Mogelijk dat de betekenis van 'machtiging' niet duidelijk was, of is veranderd. Als je dat niet goed hebt gaat je test het ook niet vinden.

[Douweegbertje]

Hier krijg ik echt de kriebels van, niet alleen qua werking van de fout, maar ook de reden. Alsof een client, dus een browser, de flaw moet verhullen. Links of rechts om is er een enorm issue. Zo'n gebruiker zou per definitie nooit bij die data mogen. De zogenoemde frontend (want daar gaat het om) staat daar absoluut los van. Zelfs al zou je een fout maken in je frontend, dan moet je dichtklappen op de backend. Al gebruik je IE6...

Als ik het nu lees, inclusief "de fix", dan blijft het gewoon mogelijk om zelf je client aan te passen en alsnog bij alle data te kunnen. Met je client aanpassen doel ik basale dingen zoals de POST waardes van een formulier te over-rullen of domweg een ID'tje ergens te veranderen.

Basis regel is dat je nooit user-data vertrouwd. Dat je een security risico hebt vanwege "we hebben deze browser niet getest" geeft jammer genoeg aan dat er nog steeds ergens iets goed fout gaat.

Ik vraag mij af of de belastingdienst iets met security doet.. ik als white hat zou graag wel eens wat meer onderzoek willen doen..

[R.di.Giovanni]

Ik kan je uit eigen ervaring melden dat de Belastingdienst zeer zeker 'iets' met security doet. Ontwikkelaars en testers zijn op de hoogte van wat er qua security allemaal in de wereld speelt, en daar wordt dan ook rekening mee gehouden. Zo wordt er, in tegenstelling tot wat anderen in deze thread beweren, wel degelijk gebruik gemaakt van het principe dat je validaties aan de server kant doet, en niet aan de client kant. Maar zoals de meeste IT-ers wel weten; software echt veilig maken is een vak, en overal waar mensen werken worden fouten gemaakt. Zo ook hier.

Wat mij persoonlijk deugd doet is het feit dat de journalist in kwestie eerst het lek heeft gemeld zodat dit met spoed gefixt kon worden, en er pas daarna over heeft geschreven. Kudos voor hem.

[hansb57]

Opmerkelijk. Omdat mijn schoonmoeder op leeftijd is en soms problemen heeft met haar lap top help ik haar soms via Team viewer. Kort geleden startte ik via Team Viewer IE op klikte op de bank link en zat meteen life in haar gegevens en kon ook bladeren. En dit terwijl alle browsers gesloten waren.

[hackerhater]

Dat klinkt alsof er iets serieus niet klopt bij die bank.
Zelfs als een buggy IE/Edge de sessie onterecht vast houd, hoort de server bij het eerste request een 401 header te gooien (https://httpstatuses.com/401)

[mutley69]

Da's wellicht niet GDPR-compliant - en dus een jackpot voor advo's (helaas).