Website NRC gaf abonnees toegang tot andermans gegevens

Een fout in de website van de krant NRC zorgde er de afgelopen drie dagen voor dat abonnees die inlogden, aangemeld werden als een ander persoon. Na het inloggen konden de gebruikers de gegevens van de andere abonnee inzien en aanpassen.

Oorzaak van de fout is de paywall die donderdag opgetrokken werd rondom de digitale editie van de krant, zo meldt Webwereld. Na het instellen van de betaalmuur zouden het inlogsysteem en de bijbehorende database van slag zijn geraakt, waardoor mensen na inloggen andermans gegevens te zien konden krijgen. Het ging hier naast naw-gegevens ook om het type abonnement en bankgegevens. Omdat het systeem dacht dat de desbetreffende gebruiker correct ingelogd was, konden de gegevens ook aangepast worden.

Naast de inlogperikelen gaf de site ook geregeld foutmeldingen, waaronder soms een 404-melding als geprobeerd werd uit te loggen. Nadat NRC op zaterdagochtend werd getipt dat de problemen nog steeds voorkwamen, besloot de krant om het inlogsysteem in onderhoudsmodus te zetten. Volgens NRC's internetchef Ernst-Jan Pfauth is er samen met de betrokken leveranciers een onderzoek gestart naar de problemen. Daarnaast zullen alle mutaties die sinds donderdag doorgevoerd zijn worden nagelopen, waarbij eventuele ongewenste wijzigingen hersteld zullen worden. NRC heeft gezegd nog met een officiële verklaring te zullen komen.

Reacties (47)

[vandijk]

Klinkt als een klassiek gevalletje van session hijacking. Dit kan veroorzaakt worden door een setCookie header die in een (proxy)cache terecht komt. Die fout kan al heel lang in een site zitten, maar als er niet ingelogged wordt, dan is die fout niet zichtbaar.
Voeg je dan ineens inloggen toe aan zo'n site, dan wordt de fout zichtbaar. Als je dan alleen in de nieuwe code gaat zoeken naar de fout, dan kan je lang zoeken :-D

[Peetz0r]

Oftewel, dit is slecht getest.
Ze dachten dat ze het getest hadden, maar hebben gene rekening gehouden met hun proxy of watdanook. Gebeurt best vaak dat je kan zien dat een belangrijk groot systeem erg slecht getest wordt. Soms is het best lastig om iets goed te testen, maar vaak genoeg zijn ze gewoon lui en/of heeft de baas er geen zin in (alsof die snapt wat er fout kan gaan ofzo)

[thegve]

Zo te lezen konden gebruikers van een (random) gebruiker de gegevens bewerken. Het lijkt mij dat als het in een reverse proxy beland was, dat je dan consequent van dezelfde gebruiker de gegevens in kan. Of van zo nu en dan wisselende ( verlopende caches ).

[Verwijderd]

Je begrijpt het beter als je wat zoekt naar die man ("internetchef" bij NRC):
"Oktober 2006, vlak voor een stage bij de Verenigde Naties in New York begon ik met bloggen. Na vier dagen legde ik een ruzie tussen Balkenende en Witteman vast, dat haalde van alles tussen RTL Boulevard en NRC Handelsblad. Ik blogde in New York stug door, kwam terug in Nederland, en reisde met internetondernemer Boris Veldhuijzen van Zanten een jaar lang de wereld over voor technologieblog The Next Web. Ergens in Nepal kreeg ik een mailtje van nrc.next, of ik een nieuwsblog wilde opzetten. Graag!"

[Remus]

Interchef is zo iets als redactiechef van de internet versie van NCR. Die heeft dus helemaal niets te maken met de achterliggende techniek, behalve misschien dat hij opdrachtgever is voor aanpassingen.

[mae-t.net]

En in dat hele terloopse staartje (behalve misschien dat hij opdrachtgever is) schuilt toch een groot gevaar. Minstens 1 van de betrokken partijen moet capabel zijn, als de opdrachtgever dat niet is, komt die verantwoording op last van de leverancier te liggen. Grote kans dus dat er geblunderd wordt. Q.E.D.

[Accesteam]

Ouch... Pijnlijk foutje van het NRC. Ben benieuwd hoe zit dit gaan verklaren tegenover hun klanten. Vertellen dat iemand mogelijk inzicht heeft gehad in hun NAW en bankgegevens is altijd lastig. Al helemaal als diezelfde persoon ook nog eens de gegevens heeft kunnen aanpassen. En dan ook voor 3 dagen

[Verwijderd]

Het is niet echt een fout van de NRC zelf, maar vooral van de systeembeheerders.

[Reactie gewijzigd door Verwijderd op 22 juli 2024 16:46]

[kywr]

NRC blijft natuurlijk verantwoordelijk, de systeembeheerders werken tenslotte in opdracht van NRC zelf.

[Reactie gewijzigd door kywr op 22 juli 2024 16:46]

[stresstak]

Dan heeft men hierbij weer genoeg stof voor een kritisch stukje

[TMDevil]

Ehu? Wat hebben de systeembeheerders dan precies verkeerd gedaan? Is het niet gewoon een fout van slechte software?

[Verwijderd]

Doet er voor de rest niet toe... Zelf schrijven ze kritische stukken over allerlei zaken, maar op deze manier zou ik ze niet meer serieus nemen als ik daar klant was.

[Verwijderd]

[AtlonXP1800]

Lekkere uitleg, een database die "van slag" raakt? Mijn kat raakt van slag als hij uit logeren moet...
Een computersysteem doet enkel wat men het opdraagt te doen, gewoon een programmeerfout dus.

[Verwijderd]

...zelfs hun foutmelding is fout

...maar Ernst Jan Pfauth heeft alles onder controle...

...de reden van deze fout is trouwens dat de NRC geld wil verdienen, als je de codes in hun style-sheets mag geloven...

[Reactie gewijzigd door Verwijderd op 22 juli 2024 16:46]

[Verwijderd]

Wtf,

die laatste slaat echt alles inderdaad. Dat kan echt niet op een site als het nrc..

Zelf denk ik niet dat het veel uitmaakt of je nu 20 of 40 bent, als je maar veel ervaring hebt met programmeren voor het web. En zo te zien ontbreekt het daar nogal aan. Een database raakt niet "in de war" zoals wordt uitgelegd, maar door "toet toet boing boing centjes verdienen"-programmeerwerk vind ik het niet raar.

Edit: En peppi en kokkie onderaan de code slaat natuurlijk ook nergens op

[Reactie gewijzigd door Verwijderd op 22 juli 2024 16:46]

[AibohphobiA BoB]

Het geeft wel aan hoe serieus NRC haar klanten neemt. Naast Peppi en Kokkie hebben ze waarschijnlijk ook de Biereco's in dienst.

[mae-t.net]

Wel aandoenlijk hoe hij de bezuinigingen op - of incapabiliteit van de ontwerpers van de nieuwe site blijft verdedigen in de commentaren op die blog. It's not a bug, it's a feature!

Daar til ik overigens veel zwaarder aan dan aan wat gerotzooi en pogingen tot humor in een stylesheet, hoewel ASCII-art wel erg over the top is.

[Reactie gewijzigd door mae-t.net op 22 juli 2024 16:46]

[moozzuzz]

display: table; /* dit zou verboden moeten worden */
--> hebben ze wel gelijk in =-)

[djiwie]

Deze bug past wel precies in de nieuwe lijn die NRC recent heeft ingezet voor de website. De oude nieuwssite is vervangen door een onbenullig weblog, er zijn al maanden problemen met het inloggen voor de digitale editie en de prijzen voor alle digitale abonnementen worden verhoogd met 20% tot 70% - en van de gewone abonnementen wordt de webtoegang weggehaald, alsof je niet al eerder hebt betaald voor dezelfde content.

Ga zo door, NRC, en alle abonnees rennen gillend weg. Naar een krant die internet wel begrijpt

[josvane]

Ik kan niet goed bevatten hoe zoiets kan ontstaan. Het lijkt mij dat zo'n soort site werkt met een front en backend. Mijn simpele kennis hiervan zegt dat user-data alleen in de backend beschikbaar is.

Als dan iemand een uniek user-id heeft en met dit ID tegen de backend praat kan het toch niet gebeuren dat je de verkeerde gegevens krijgt.

Daarnaast lijkt mij dat het inloggen los staat van het abbo systeem. Dus wat de intergratie hiervan te maken heeft met inlogsysteem snap ik niet.

[Verwijderd]

Te veel IT-ers hebben te weinig verstand van security tegenwoordig. Als je een bus met passagiers wilt vervoeren heb je een extra rijbewijs nodig, maar in de IT is het doodnormaal dat iedere afgestudeerde achter de knoppen mag zitten van systemen met (belangrijke) persoonsgegevens.

[Reactie gewijzigd door Verwijderd op 22 juli 2024 16:46]

[YopY]

Dit heeft niks te maken met een falend verstand aan beveiliging, dit lijkt gewoon keihard een fout bij de release van nieuwe software te zijn, aan de ene kant bij degene die (wat lijkt op) de verkeerde versie van de software online gezet heeft, aan de andere kant bij degenen die verantwoordelijk zijn voor het testen van die software.

Zoals in het artikel aangegeven lijkt het erop dat de database van slag raakte, waardoor mensen als andere personen inlogden. Ik kan me moeilijk voorstellen hoe een database op zo'n manier van slag kan raken zonder dat er fouten in de software zelf zitten, maar dat terzijde - het feit dat een tester dit niet opmerkte, en dat het blijkbaar gedurende twee volle dagen (donderdag tot zaterdagochtend) stuk was zonder dat het offline gehaald werd, zegt genoeg over hun release en testmanagement, danwel het gebrek daaraan.

dus, niks met te weinig verstand van security hebben van ITers. En nee, niet elke afgestudeerde komt achter de knoppen van zoiets, niet zonder dat ze een verantwoordelijke boven hun hebben. Of geloof je zelf dat een vroege twintiger dit in zijn eentje gebouwd en online gepleurd heeft?

[mae-t.net]

Release- en testmanagement heeft alles met security te maken!

En nee, een vroege twintiger heeft dit niet in zijn eentje gebouwd en online gepleurd mag ik hopen (hoewel dat ook niet onmogelijk is, en zelfs dat kan ook nog gewoon goed gaan dus dat zegt niet alles), maar de kwaliteit van sommige systemen suggereert wel dat er toch genoeg verkeerde mensen op de verkeerde plek zijn zonder het te weten.

[Reactie gewijzigd door mae-t.net op 22 juli 2024 16:46]

[]Byte[]

Waarschijnlijk zijn er een aantal stappen in de OTAP overgeslagen...
Voor diegene die het niet weten,
Bij softwareontwikkeling heb je een aantal omgevingen waarbij je de software over een aantal fases in productie gaat nemen.
Ontwikkel-omgeving
Test-omgeving
Acceptatie-omgeving
Productie-omgeving

Als ik dit zo lees heeft de Test-omgeving hun werk onvoldoende gedaan en de Acceptatie-testen lijken helemaal te zijn overgeslagen.

[PolarBear]

Het zal niet de eerste keer zijn dat er wel een OTAP omgeving is maar dat het overzetten van de programatuur dusdanig complex is dat juist daar fouten worden gemaakt.

[Bor]

Het zal ook niet de eerste keer zijn dat er bij het gebruik van OTAP alleen focus ligt op de functionele testen ipv ook security als onderdeel van het traject te maken.

[AibohphobiA BoB]

Meestal omdat er in de basis geen rekening mee is gehouden dat het overgezet moet gaan worden. Dus blijft het een fout van slechte IT-ers.

[Remus]

Het gebruik van OTAP is een optie, maar wordt echt niet bij alle methodieken toegepast, en dus ook niet bij alle bedrijven. En doen alsof toepassen OTAP dit soort problemen wel aan het licht gebracht zou hebben is vreselijk naïef tav het nut van OTAP.

[Verwijderd]

Onzin. Als security geen onderdeel van het ontwerp c.q. testplan is, dan levert geen enkele methode een veilig systeem op.

[humbug]

Ja ja. En alles is goed gegaan tijdens het Ontwikkelen.

Problemen in productie liggen in feite altijd aan meerdere factoren. Ook heb je te maken met een testomgeving die niet altijd vergelijkbaar is met de productie omgeving.

[arjankoole]

Waarschijnlijk zijn er een aantal stappen in de OTAP overgeslagen...

Zelfs als je OTAP perfect volgt, kan je alsnog voor enorme verrassingen komen te staan bij de Productie fase. Je verkleint alleen de kans/risico dat het gebeurt, maar dat is eigelijk meer een theorie dan iets anders.

Iedere ouwe rot in het vak kan je dat vertellen.

[Akino]

en apparaat(en) verkopen en neerzetten van +10000 euro,maar vervolgens niet weten hoe het werkt,wat het kan en wat je ermee moet.

[kmf]

Nou, dan is dit toch wel weer voordelig.. dan zitten je persoonsgegevens toch maar op 1 plek.

En dat hoeven niet eens echte of volledige gegevens te zijn, als je met prepaidkaarten betaald. Als het dan wordt gekraakt, dan nog is de schade beperkter.