Overheid zet DigiD weer online na patchen 'ernstig' beveiligingslek
De overheid heeft de dienst voor het digitaal controleren van de identiteit van burgers, DigiD, weer online gezet. De dienst ging woensdagochtend offline vanwege een 'ernstig' beveiligingslek in Ruby On Rails, dat gebruikt wordt voor DigiD.
DigiD is na bijna een dag downtime donderdag weer beschikbaar. Burgers konden in die tijd nergens inloggen met DigiD, dat onder meer wordt gebruikt voor identificatie bij gemeenten en andere overheden. DigiD moest offline om de patch voor het beveilingslek uit te rollen en te testen voordat gebruikers de dienst weer zouden gebruiken. "We willen het zekere voor het onzekere nemen", zei Michel Groeneveld, woordvoerder van overheids-ict-dienst Logius, woensdag tegen Tweakers. "Zo willen we misbruik van het lek voorkomen."
Het gaat om twee lekken waarvoor Ruby on Rails dinsdag een patch uitbracht. Volgens het Nationaal Cyber Security Centrum maken die kwetsbaarheden het onder meer mogelijk om authenticatie te omzeilen, sql-injecties uit te voeren, eigen code op afstand uit te voeren en een denial of service-aanval uit te voeren.
DigiD is in de nacht van dinsdag op woensdag kwetsbaar geweest; de lekken waren toen al bekend, maar DigiD was toen online. Woensdagochtend ging de identificatiedienst offline.
Reacties (54)
Werk.nl zit nog op slot 'wegens storing Digid'. Op Digid.nl, waar naar verwezen wordt, staat niets (laatste nieuws is van Mei)
Ik kon gisteravond al wel inloggen op DigiD, maar uwv.nl zit ook nu nog steeds op slot.
Waarom is het gebouwd op RoR Ruby? Waarom is er niet voor PHP of ASP gekozen? Ben wel benieuwd waarom.
[Reactie gewijzigd door KvanSteijn op donderdag 10 januari 2013 07:59]
Daar zullen ze bij Logius hun redenen voor gehad hebben; zo'n platform ontwikkel je niet op het eerste het beste Framework. Overigens is je vraag meteen al te beantwoorden met "PHP en ASP zijn geen frameworks maar programmeertalen. Er is bewust voor een framework gekozen om een sneller en effectiever ontwikkeltraject en beheerssituatie te hebben".
Zal wel via aanbesteding gedaan zijn en geen technische eisen opgenomen. De goedkoopste wint en die had RoR in gedachten. Waarom denk je dat er bewust een technische keuze door Logius is gedaan?
Waarom zouden er geen technische eisen gesteld zijn voor jou? Omdat er voor RoR is gekozen? RoR is nou juist een groot, robuust en stabiel framework, en dat zou best eens 1 van de technische eisen geweest kunnen zijn. Tezamen met : moet SAML ondersteunen.Zal wel via aanbesteding gedaan zijn en geen technische eisen opgenomen. De goedkoopste wint en die had RoR in gedachten. Waarom denk je dat er bewust een technische keuze door Logius is gedaan?
Tenzij we de aanbesteding onder ogen krijgen is daar eigenlijk niets over te zeggen.
Ik wist niet dat RoR een framework is, dan stel ik mijn vraag fout. Waarom is er dan voor Ruby gekozen?
Waarom niet? Wat maakt Ruby in jouw ogen slechter dan PHP of ASP (terwijl ASP ook nog een beetje een verwarrende term is. ASP is al redelijk verouderd en AP != ASP.NET en ASP.NET kan ook weer C# of VB zijn). Het feit dat je niet weet dat RoR een framework is bovenop Ruby geeft aan dat je wellicht niet veel van Ruby weet en daarom vind ik jouw vraag een beetje vreemd.
Ruby en het web-app-framework Ruby on Rails zijn heel volwassen. Het feit dat er zo'n beveiligingslek wordt gevonden heeft te maken met het feit dat er een hele grote groep gebruikers, researchers en beveiligingsexperts dagelijks met de open-source code bezig zijn.
Ruby en het web-app-framework Ruby on Rails zijn heel volwassen. Het feit dat er zo'n beveiligingslek wordt gevonden heeft te maken met het feit dat er een hele grote groep gebruikers, researchers en beveiligingsexperts dagelijks met de open-source code bezig zijn.
[Reactie gewijzigd door armageddon_2k1 op donderdag 10 januari 2013 08:20]
Nou de vraag (ook op het forum) was eerder, hoe is het mogelijk dat er zo'n gigantisch beveiligingslek in kan zitten. Dat doet bij mij toch wel twijfelen of RoR wel zo'n volwassen framework is en of het niet uit zijn voegen begint te barsten.Ruby en het web-app-framework Ruby on Rails zijn heel volwassen. Het feit dat er zo'n beveiligingslek wordt gevonden heeft te maken met het feit dat er een hele grote groep gebruikers, researchers en beveiligingsexperts dagelijks met de open-source code bezig zijn.
Tja, waarom zijn andere sites gebouw in PHP of ASP? ieder heeft zo zijn/haar voorkeur.. En elke framework heeft wel zo zijn voordelen en zijn nadelen.. Omdat 'jij' misschien graag met framework a werkt wil nog niet zeggen dat dat ook het beste framework is, en tja, dan kom ik weer terug op 'wat is het beste framework'..
Elke framework heeft ook zo zijn lekken, en het is niet alsof RoR zo'n weinig gebruikt framework is..
Elke framework heeft ook zo zijn lekken, en het is niet alsof RoR zo'n weinig gebruikt framework is..
Erg kwalijke zaak. Bij de onderhoudsmelding stond ook 'offline voor onderhoud'. Of dit nu de lading dekt... juist de overheid zou degene moeten zijn die zegt waar het op staat: 'offline wegens ernstig beveiligingslek in één van de meest gevoelige informatiesystemen in Nederland'.
Vooral dat het lek in Rails al een dag van tevoren bekend was stoot mij voor de borst. Juist SQL-injecties en deze andere problemen zijn kritiek voor DigiD. Het lijkt me dat wanneer er een Security Advisory uitkomt dat de hele mikmak gewoon direct offline gehaald wordt - automatisch als er een systeembeheerder niet wakker is.
Vooral dat het lek in Rails al een dag van tevoren bekend was stoot mij voor de borst. Juist SQL-injecties en deze andere problemen zijn kritiek voor DigiD. Het lijkt me dat wanneer er een Security Advisory uitkomt dat de hele mikmak gewoon direct offline gehaald wordt - automatisch als er een systeembeheerder niet wakker is.
Ik vind dat de overheid in deze erg goed opgetreden heeft.
Wat hadden ze dan moeten doen ?
Wat hadden ze dan moeten doen ?
Het lijkt mij dat Rails een Security Advisory uitstuurt in dit soort gevallen. Het lijkt me dan ook een kleine moeite om bij een SA volautomatisch de hele service offline te gooien. False positives zou ik dan voor lief nemen. 
False positives voor lief nemen bij 1 van de infrastructuur services van de overheid? Alle overheidssites gebruiken het systeem. Bij het offline er van zijn kan heel veel werk opeens niet meer gedaan worden. Dan neem je downtime echt niet voor lief.
Downtime voor zulke services wil je inderdaad niet. Digid wordt steeds kritieker omdat steeds meer mensen hun zaken via Internet willen regelen en de overheid daar in mee moet gaan.
Keihard liegen over de ernst van het lek is daarentegen natuurlijk ook niet zoals het hoort.
Er wordt niet bekend gemaakt vanaf welke versie men heeft ge-update. Daarom acht ik het zeer waarschijnlijk dat dit lek maanden lang aanwezig is geweest.
Keihard liegen over de ernst van het lek is daarentegen natuurlijk ook niet zoals het hoort.
De vorige versie van Ruby 3.2.10 was van 2 januari, de versie daarvoor stamt uit november vorig jaar. Het is een overheidsservice, dus het is vrijwel zeker dat ze nooit direct updaten nadat er een nieuwe versie van Ruby uit komt.DigiD is in de nacht van dinsdag op woensdag kwetsbaar geweest; de lekken waren toen al bekend, maar DigiD was toen online. Woensdagochtend ging de identificatiedienst offline.
Er wordt niet bekend gemaakt vanaf welke versie men heeft ge-update. Daarom acht ik het zeer waarschijnlijk dat dit lek maanden lang aanwezig is geweest.
Je legt dan een groot deel van de overheidssites plat. Natuurlijk laat je daar een systeembeheerder niet over beslissen, laat staan een geautomatiseerd systeem, daar laat je specialisten naar kijken.
Als er voor elke melding automatisch het systeem platgegooid wordt wegens een 'beveiligingslek' dan ben ik bang dat het vertrouwen in DigiD heel snel geschaad wordt.
Elke vorm van security patches is voor een leek al snel een reden om te denken dat zijn gegevens op straat liggen.
In dit geval is er naar mijn mening goed gehandeld. Ze hebben niet overhaast gereageerd, het goed overdacht en transparant naar buiten gecommuniceerd.
Tevens ben ik er van overtuigd dat ze echt wel het nodig hebben gemonitord na bekendmaking van de bug.
Elke vorm van security patches is voor een leek al snel een reden om te denken dat zijn gegevens op straat liggen.
In dit geval is er naar mijn mening goed gehandeld. Ze hebben niet overhaast gereageerd, het goed overdacht en transparant naar buiten gecommuniceerd.
Tevens ben ik er van overtuigd dat ze echt wel het nodig hebben gemonitord na bekendmaking van de bug.
Tja, dus dat zou dan hebben betekend dat DigiD een hele week niet gebruikt had kunnen worden omdat er mogelijk misbruik van gemaakt zou kunnen worden, vergeet niet dat RoR pas dinsdag een patch hiervoor beschikbaar heeft gesteld.. Het zou mij niet verbazen als ze wel op de achtergrond de boel in de tussentijd in de gaten hebben gehouden op misbruik..
ELK systeem is kwetsbaar, en als je denkt dat het niet zo is en dat jouw (zelfgebouwde) systeem wel 100% veilig is, dan ben je wel heel erg naief..
ELK systeem is kwetsbaar, en als je denkt dat het niet zo is en dat jouw (zelfgebouwde) systeem wel 100% veilig is, dan ben je wel heel erg naief..
De CVE's zijn 08 Jan 2013 12:15:06 PST de wereld in gebracht. Dat is dinsdagavond 9:15 Nederlandse tijd.
We weten niet of Logius toen al direct actie ondernomen heeft; maar wél dat ze woensdagochtend, in alle vroegte, de boel offline hebben gehaald.
Tja, dus dat zou dan hebben betekend dat DigiD een hele week niet gebruikt had kunnen worden omdat er mogelijk misbruik van gemaakt zou kunnen worden
Is dus vreemd. Het zou betekend hebben dat ze om 9:15 alles al platgegooid hadden; en DigiD zeven uur langer offline geweest was; uitgaande dat ze het dan ook niet eerder weer terug online hadded gebracht maar ook donderdachochtend. Geen week, dus.
We weten niet of Logius toen al direct actie ondernomen heeft; maar wél dat ze woensdagochtend, in alle vroegte, de boel offline hebben gehaald.
Tja, dus dat zou dan hebben betekend dat DigiD een hele week niet gebruikt had kunnen worden omdat er mogelijk misbruik van gemaakt zou kunnen worden
Is dus vreemd. Het zou betekend hebben dat ze om 9:15 alles al platgegooid hadden; en DigiD zeven uur langer offline geweest was; uitgaande dat ze het dan ook niet eerder weer terug online hadded gebracht maar ook donderdachochtend. Geen week, dus.
Het eerste wat je bij zo'n melding doet is kijken of het jou daadwerkelijk treft. Je gaat niet rücksichtslos een belangerijke dienst offline schoppen, om nog maar te zwijgen dat je alle gebruikers (de ministeries) ook op de hoogte moet stellen. (Reken maar dat ze daar een SLA mee hebben)
Er zijn honderden factoren die een rol spelen bij zoiets, dus ik vind dat ze alles bij elkaar enorm snel hebben gehandeld. Ze hebben het enorm goed gedaan vind ik.
Er zijn honderden factoren die een rol spelen bij zoiets, dus ik vind dat ze alles bij elkaar enorm snel hebben gehandeld. Ze hebben het enorm goed gedaan vind ik.
Ben ik nu de enige die vind dat DigiID dit goed heeft aangepakt?
Melding krijgen van een beveiligingslek, offline halen, oplossen en terug online zetten.
En ze hebben niets afgeschoven, ze hebben de fout ook toegegeven en hun excuses aangeboden. Wat zouden ze nog meer moeten doen?
Melding krijgen van een beveiligingslek, offline halen, oplossen en terug online zetten.
En ze hebben niets afgeschoven, ze hebben de fout ook toegegeven en hun excuses aangeboden. Wat zouden ze nog meer moeten doen?
Ben het met je eens. Prima actie op ondernomen.
Je bent niet de enige hoor. Ik zei gisteren al dat ze netjes hebben gehandeld. Bugs en lekken in frameworks komen nou eenmaal voor of het nou RoR, .NET, ASP.NET of PHP is dat maakt niet uit. Dit was zelfs een lek in het framework zelf en dus geen security lek door een ontwikkelaar door Logius dus dan kun je al moeilijk iets verwijten. De overlapping van dat het de vorige dag al bekend was heeft natuurlijk gewoon te maken met tijdzone verschil en kijken hoe ernstig de lek natuurlijk was. Ze hebben zo snel mogelijk gehandeld en als je dat vergelijkt met hoe de overheid in het verleden is omgegaan (lekken die maanden blijven zitten) is dit heel netjes.
Het is niet zo dat het de vorige dag pas bekend was, nee het was vorige week al bekend, maar vorige dag was de patch pas beschikbaar (tja, en daar kun je zelf weinig aan doen)..
Waar baseer je dat op? Ik denk dat je in de war bent met een andere vulnerability. Het ging niet om CVE-2012-5664 (2 jan) maar om CVE-2013-0156 die pas 8 januari bekend is gemaakt.
Ze hadden misschien iets sneller kunnen zijn, maar dit vind ik echt prima opgelost. Als het gevaar reëel is offline halen, zo snel mogelijk patchen, alles weer testen en binnen 24 uur weer online. Chapeau.
Als het regulier onderhoud was geweest, dan was het natuurlijk anders: dat moet je zo veel mogelijk proberen te doen zonder dat iemand er iets van merkt. Maar dit was een beveiligingslek, en zo lang als het systeem bereikbaar is is het kwetsbaar. Goed opgelost.
Als het regulier onderhoud was geweest, dan was het natuurlijk anders: dat moet je zo veel mogelijk proberen te doen zonder dat iemand er iets van merkt. Maar dit was een beveiligingslek, en zo lang als het systeem bereikbaar is is het kwetsbaar. Goed opgelost.
Helemaal mee eens. Pro actief gehandeld, de boel offline gehaald, de patches doorgevoerd en getest. Een dergelijk groot lek zit (als het wordt misbruikt) natuurlijk wel in de Diginotar affaire regionen en een fout van dergelijk kaliber kunnen ze zich ook niet twee keer veroorloven. Het is jammer voor het niet bereikbaar zijn, maar het is in ieder's belang dat het wordt opgelost dus dan maar even niet online... Eigenlijk hadden ze direct de boel offline moeten halen toen het lek bekend werd, maar daar zullen vast nog de nodige telefoontjes / accorderingsrondjes van management voor nodig zijn geweest. Dus nog best snel, voor een ambtelijke organisatie 
[Reactie gewijzigd door 4np op donderdag 10 januari 2013 08:42]
Als ze het direct de boel offline hadden gehaald, dan had DigiD dus meer dan een week stil gelegen, en dat kan dus echt niet. Ze hebben het netjes gepatched toen de patch beschikbaar kwam (dinsdag), en waarschijnlijk tot die tijd de boel goed in de gaten gehouden op misbruik..
Nee. Dan was het dinsdagavond 21:15 offline gehaald. Pas toen was dit lek en de CVE bekendgemaakt.
Je verwart waarschijnlijk met CVE-2012-5664 (2 jan) ;Dat was een ander lek, een klein, in slechts heel beperkte situaties exploitable lek. We kennen de exacte opzet van DigiD niet, maar het is zeer onwaarschijnlijk dat dit probleem bij hun exploitable was (voorwaarden waren enkele specifieke versies van libraries én het gebruik van AuthLogic een niet erg populaire addon die dan ook nog eens op een speficieke manier geconfigureerd moet worden).
CVE-2013-0156 is 8 januari 21:15:06 vrijgegeven. Dat is het lek waar het hier om gaat.
Je verwart waarschijnlijk met CVE-2012-5664 (2 jan) ;Dat was een ander lek, een klein, in slechts heel beperkte situaties exploitable lek. We kennen de exacte opzet van DigiD niet, maar het is zeer onwaarschijnlijk dat dit probleem bij hun exploitable was (voorwaarden waren enkele specifieke versies van libraries én het gebruik van AuthLogic een niet erg populaire addon die dan ook nog eens op een speficieke manier geconfigureerd moet worden).
CVE-2013-0156 is 8 januari 21:15:06 vrijgegeven. Dat is het lek waar het hier om gaat.
Nee DigiD heeft het goed aangepakt. Waar ik me wel aan geërgerd heb is de verslaggeving in het journaal. Zoals RTL 4 het presenteerde was het een fout vanuit DigiD/Logius was waarbij bijna zeker 1 dag iedereen inzage had in alle gegevens.
Terwijl dit is nu net een probleem wat je hun niet aan kan rekenen (tenzij je een enorme azijnpisser bent)
Terwijl dit is nu net een probleem wat je hun niet aan kan rekenen (tenzij je een enorme azijnpisser bent)
Meerdere site`s die werken met DigiD zit nog op slot, maar dat ligt bij de site`s zelf, ze hebben tijdelijk de button gelinkt naar een storingpage / custompage.
Zodra ze groen licht hebben zullen ze het aanpassen, dus later op de dag nog eens kijken of je wel kunt inloggen.
Aldus een medewerker die ergens werkt waar ze DigiD gebruiken, ik ken hem persoonlijk, en dit hebben ze te horen gekregen per mail gekregen van Logius.
Zodra ze groen licht hebben zullen ze het aanpassen, dus later op de dag nog eens kijken of je wel kunt inloggen.
Aldus een medewerker die ergens werkt waar ze DigiD gebruiken, ik ken hem persoonlijk, en dit hebben ze te horen gekregen per mail gekregen van Logius.
Welke sites ook gebruik maken van dit programma? Onderzoeksjournalist en ICT-kenner Brenno de Winter zegt op BNR "Je kunt bijvoorbeeld denken aan Twitter of aan Groupon. Die maken daar ook gebruik van. Zo zijn er nog veel meer voorbeelden. Het lek is heel erg vervelend. Waar het om gaat is dat het mogelijk is dat je in de database van het systeem kan komen en daar informatie uit kunt ophalen of kunt manipuleren. Dat zou voor DigiD enorm vervelend zijn."
Zo zou je bijvoorbeeld hele contactenlijsten kunnen ophalen, zegt De Winter. "Als dat lukt, heb je ineens een enorme marketingdatabase en dat is juist het bestaanrecht van Groupon. Dus de ernst van zo'n lek is enorm. Wat heel erg opvallend is dat geen gebruik is gemaakt van de mogelijkheid om de broncode te checken. Bijvoorbeeld bij de Rijksoverheid. Als iets zo enorm belangrijk is, kan ik me voorstellen dat je besluit de code van het platform na te lopen. Dat lijkt niet te zijn gebeurd. Het type fout had toch wel ontdekt kunnen worden."
Bron: http://www.bnr.nl/nieuws/...had-ontdekt-kunnen-worden
Zo zou je bijvoorbeeld hele contactenlijsten kunnen ophalen, zegt De Winter. "Als dat lukt, heb je ineens een enorme marketingdatabase en dat is juist het bestaanrecht van Groupon. Dus de ernst van zo'n lek is enorm. Wat heel erg opvallend is dat geen gebruik is gemaakt van de mogelijkheid om de broncode te checken. Bijvoorbeeld bij de Rijksoverheid. Als iets zo enorm belangrijk is, kan ik me voorstellen dat je besluit de code van het platform na te lopen. Dat lijkt niet te zijn gebeurd. Het type fout had toch wel ontdekt kunnen worden."
Bron: http://www.bnr.nl/nieuws/...had-ontdekt-kunnen-worden
Die BNR conclusie is wel boterzacht. Had kunnen ontdekt worden. Zo lust ik er nog wel een paar. Als je een omvangrijke codebase hebt, dan kun je niet alles even controleren. En als de codebase al ouder is, dan zijn er w.s. ook geen ontwikkelaars die alle ins & outs nog weten. En dan nog: reviews voorkomen echt niet alle fouten. Waar gehakt wordt :-).
Ik vind de conclusie van BNR dus net iets te gemakkelijk. Lijkt meer vanuit journalistieke scoringsdrang geschreven te zijn dan dat we hier over feiten praten. Per definitie zit er in code altijd fouten (zijn vaste getallen voor per 1000 regels). Bij een veel gebruikt framework, dat goed doordacht in elkaar steekt (ik weet niet of dat voor Ruby het geval is), zal het aantal fouten eerder lager dan hoger liggen, vergeleken met eigen verse code.
Ik vind de conclusie van BNR dus net iets te gemakkelijk. Lijkt meer vanuit journalistieke scoringsdrang geschreven te zijn dan dat we hier over feiten praten. Per definitie zit er in code altijd fouten (zijn vaste getallen voor per 1000 regels). Bij een veel gebruikt framework, dat goed doordacht in elkaar steekt (ik weet niet of dat voor Ruby het geval is), zal het aantal fouten eerder lager dan hoger liggen, vergeleken met eigen verse code.
Nou, dan weet die zogrnaamde onderzoeksjournalist en ICT-kenner 1 grote beunhaas die er echt geen verstand van heeft, want zo simpel is het allemaal niet.. Net zoals kdekker al zegt, zelfs met code-review komen een hoop fouten niet naar boven.. En sommige zeggen bv dat TDD (test driven development) alle fouten voorkomt, nou ook dat klopt voor geen meter, aangezien de test zelf ook al fout kan zijn (heb ik nu al vaak genoeg voorbij zien komen)..
Je hebt gelijk. Ik ben geen doorgewinterde Rails expert, maar ken de in's en outs goed genoeg om de complexiteit van dit probleem goed te doorgronden.
Het is een héél ingewikkeld lek. En feitelijk ook geen SQL-injectie, maar code-injectie; Het feit dat Brenno dat niet snapt geeft aan dat hij zeker een toontje lager had moeten zingen.
Mooi detail is dat dit specifieke lek ontdekt is in navolging van een eerder lek, op 2 januari, wat wél een SQL-injectie-lek was, maar welke slechts in heel specifieke configuraties ook exploitable was. Dat lek heeft een heleboel onderzoekers op een spoor gezet; wat geleid heeft tot het ontdekken van het huidige lek.
Merk ook op dat om dit lek uit te leggen; de proof of concepts; pagina's tekst en voorbeelden nodig zijn; dat is een indicatie van hoe complex het is.
Heel in het kort: op plekken waar je in de rail-applicatie XML POST/PUT verwerkt, kan een aanvaller XML insturen waarin hij gebruik maakt van een heel obscure "feature" in XML. Hierdoor worden bepaalde beveiligingen die normaliter over die XML worden uitgeschud, omzeild. Wanneer je de XML dan vervolgens nog prepareert met extra code kun je die code in de applicatie uitgevoerd krijgen. In deze uitleg ga ik kort door de bocht, maar de essentie is er. En duidelijk is dat het erg complex is en een code-review door een overheid écht niet achter dit lek gekomen was.
Het is een héél ingewikkeld lek. En feitelijk ook geen SQL-injectie, maar code-injectie; Het feit dat Brenno dat niet snapt geeft aan dat hij zeker een toontje lager had moeten zingen.
Mooi detail is dat dit specifieke lek ontdekt is in navolging van een eerder lek, op 2 januari, wat wél een SQL-injectie-lek was, maar welke slechts in heel specifieke configuraties ook exploitable was. Dat lek heeft een heleboel onderzoekers op een spoor gezet; wat geleid heeft tot het ontdekken van het huidige lek.
Merk ook op dat om dit lek uit te leggen; de proof of concepts; pagina's tekst en voorbeelden nodig zijn; dat is een indicatie van hoe complex het is.
Heel in het kort: op plekken waar je in de rail-applicatie XML POST/PUT verwerkt, kan een aanvaller XML insturen waarin hij gebruik maakt van een heel obscure "feature" in XML. Hierdoor worden bepaalde beveiligingen die normaliter over die XML worden uitgeschud, omzeild. Wanneer je de XML dan vervolgens nog prepareert met extra code kun je die code in de applicatie uitgevoerd krijgen. In deze uitleg ga ik kort door de bocht, maar de essentie is er. En duidelijk is dat het erg complex is en een code-review door een overheid écht niet achter dit lek gekomen was.
Hmm, zo'n systeem zou ongeacht de taal in principe nooit op wat voor bloated framework dan ook gebouwd moeten worden. Een security review van je code betekent alleen wat als je vertrouwen in je fundering minimaal net zo hoog is als wat je van je eigen codebase verwacht. Als je bouwt op bloated frameworks en/of servers zoals Rails, Django, Spring, etc, dan heb je bij voorbaat de handoek eigenlijk al in de ring gegooid.
Ideaal gezien zou je dit soort systemen eigenlijk from-the-ground-up met Caha of Joe-E willen bouwen. Dat zijn in capability secure versies van de mainstream talen JavaScript en Java die uitermaten geschikt zijn om high integrity systemen mee te bouwen.
http://en.wikipedia.org/wiki/Object-capability_model
Ideaal gezien zou je dit soort systemen eigenlijk from-the-ground-up met Caha of Joe-E willen bouwen. Dat zijn in capability secure versies van de mainstream talen JavaScript en Java die uitermaten geschikt zijn om high integrity systemen mee te bouwen.
http://en.wikipedia.org/wiki/Object-capability_model
Hoezo 'bloated' frameworks? Jouw opmerking klinkt een beetje als het Not Invented Here syndroom. De betreffende frameworks worden over de hele wereld gebruikt en door vele mensen gesupport (daarom dat er nu zo snel een patch is uitgebracht)
Als je alles zelf van scratch gaat bouwen moet je die kennis allemaal zelf op doen en ben je helemaal zelf verantwoordelijk (ook als het helemaal mis gaat)
Als je alles zelf van scratch gaat bouwen moet je die kennis allemaal zelf op doen en ben je helemaal zelf verantwoordelijk (ook als het helemaal mis gaat)
Bij zo'n framework gebruik je meestal maar procenten van wat er inzit, maar expose je jezelf vaak wel voor bugs in stukken die je niet gebruikt. Voor de meeste toepassingen is dat geen enkel probleem. Een systeem als DigID zou echter 'high-integrity' moeten zijn, en binnen high-integrity computing is het gebruik van een mega groot untrusted framework gewoonweg geen serieuse optie. Ja het kost je meer tijd als je geen framework gebruikt, maar de risico's zijn gewoon te hoog om het wel te gebruiken.
edit:
Er is een framework dat mogelijk wel een beetje helpt, en je Joe-E laat gebruiken:
http://waterken.sourceforge.net/
Het laat nog een heel stuk dat je zelf zal moeten doen, maar het is in ieder geval een goede stevige fundering.
edit:
Er is een framework dat mogelijk wel een beetje helpt, en je Joe-E laat gebruiken:
http://waterken.sourceforge.net/
Het laat nog een heel stuk dat je zelf zal moeten doen, maar het is in ieder geval een goede stevige fundering.
[Reactie gewijzigd door pibara op donderdag 10 januari 2013 09:35]
Pibara, ik vind jou stelling wel een beetje raar. Ja elke taal heeft zo zijn problemen, bugs.
Java met haar beveiligings lekken die pas 3 maanden later worden gedicht.
Je kan simpelweg niet overal rekening mee houden. Misschien wil je ons suggereren om de besturing systeem, compilers, programmeer talen, web servers etc.. zelf te schrijven? En een platform als DigID in 30 jaar ontwikkelen? Dan had de volgende artikel op Tweakers gestaan "DigID kostte de overheid xxxx miljoen euro.". Kijken wat jou reactie dan was geweest....
Java met haar beveiligings lekken die pas 3 maanden later worden gedicht.
Je kan simpelweg niet overal rekening mee houden. Misschien wil je ons suggereren om de besturing systeem, compilers, programmeer talen, web servers etc.. zelf te schrijven? En een platform als DigID in 30 jaar ontwikkelen? Dan had de volgende artikel op Tweakers gestaan "DigID kostte de overheid xxxx miljoen euro.". Kijken wat jou reactie dan was geweest....
Sorry hoor, maar ook die Caha of Joe-E zal uiteindelijk blijken dat het niet zo veilig is als je denkt.. Het voordeel van zulke frameworks gebruiken is juist omdat je niet het wiel opnieuw moet gaan uitvinden, EN omdat dat soort frameworks de meeste securitybugs er na een tijd wel uit zijn.. Het is juist gevaarlijker om zo'n systeem op een eigen nieuw framework (die vergelijkbare functionaliteiten heeft) te bouwen juist omdat dat framework niet veel gebruikt wordt en daarmee dus lang zal duren voordat ernstige fouten naar boven gaan komen, en NEE er is GEEN! systeem die er voor kan zorgen dat jouw framework 100% veilig is..
100% veilig nee, veiligheid is een combinatie van de pijlers 'robuustheid', 'beschikbaarheid' en 'vertrouwlijkheid', en je kunt die drie noot allemaal 100% afdichten. Vroeger (en bij veel bedrijfen trouwens nu nog steeds) was de prioriteit tussen deze drie:
1) Bechikbaarheid.
2) Vertrouwlijkheid.
3) Robuusteid.
De laatste jaren komen we er steeds meer achter dat je deze prioritering beter om kunt draaien. Dat als je een robuust systeem maakt, dat het daarmee veel eenvoudiger is on vertrouwlijkheid goed te impementeren, en dat het best mee valt welke beschikbaarheidsoffers je daarvoor moet brengen. Wat betekent dit, als je een systeem wilt bouwen dat veilig genoeg is voor DigID, EPD, stemcomputers, etc, dan is een eerste vereiste dat je de basis Principle Of Least Authority high-integrity-computing beginselen door je hele systeem gebruikt. Je kiest een object-capability taal (of subset van een taal met o-cap eigenschappen), ontwerpt je software volgens POLA, bepaalt via architectuur analyse wat de critische onderdelen van je software zijn, en laat op die onderdelen een grondige security review doen.
Nee, de 100% veilig haal je niet, maar al je je boos maakt en de richtlijnen goed volgt, dan kun je voor 99% zeker zijn dat de robuustheid en vertrouwlijkheid van je applicatie 100% in orde zijn.
1) Bechikbaarheid.
2) Vertrouwlijkheid.
3) Robuusteid.
De laatste jaren komen we er steeds meer achter dat je deze prioritering beter om kunt draaien. Dat als je een robuust systeem maakt, dat het daarmee veel eenvoudiger is on vertrouwlijkheid goed te impementeren, en dat het best mee valt welke beschikbaarheidsoffers je daarvoor moet brengen. Wat betekent dit, als je een systeem wilt bouwen dat veilig genoeg is voor DigID, EPD, stemcomputers, etc, dan is een eerste vereiste dat je de basis Principle Of Least Authority high-integrity-computing beginselen door je hele systeem gebruikt. Je kiest een object-capability taal (of subset van een taal met o-cap eigenschappen), ontwerpt je software volgens POLA, bepaalt via architectuur analyse wat de critische onderdelen van je software zijn, en laat op die onderdelen een grondige security review doen.
Nee, de 100% veilig haal je niet, maar al je je boos maakt en de richtlijnen goed volgt, dan kun je voor 99% zeker zijn dat de robuustheid en vertrouwlijkheid van je applicatie 100% in orde zijn.
Jezus, 't is ook nooit goed met jullie.Hmm, zo'n systeem zou ongeacht de taal in principe nooit op wat voor bloated framework dan ook gebouwd moeten worden.
Gebruiken ze een framework en is er eens iets mis, moeten ze 't zelf maken want die shit is toch veel te belangrijk om een open source framework voor te gebruiken.
Maken ze 't zelf en is er iets mis, hadden ze een open source framework moeten gebruiken want dan zou die fout er al 30 keer uitgehaald zijn en 't zou nog goedkoper zijn ook.
Het is heel simpel, 95+% van de gevallen zijn je systeemintegiteitseisen dusdanig dat een standaard web framework hardstikke goed voldoet, en dan moet je het ook gewoon gebruiken. Er zijn echter een paar procent van de gevalen, laten we zeggen DigID, EPD, stem-machines, etc waarbij de eisen een flink stukje hoger zouden moeten liggen dan voor de gemiddelde app. In die (en alleen die) situaties zou je gebruik moeten maken van de principes en technologieen die nodig zijn om high-integrity systemen te maken. De gebruikelijke frameworks vallen dan eigenlijk gewoon altijd af. Dat kost je meer tijd/geld (naar mijn ervaring tussen de 50% en 200% meer), maar dan heb je een systeem waar je echt vertrouwen kunt hebben. Met de genoemde object-capability talen kun je de benodigde ontwikkeltijd trouwens behoorlijk naar beneden brengen, en omdat het veilige subsets van bekende talen zijn zijn ze behoorlijk rap te leren. Helaas zijn er echter nog weinig bedrijven die Joe-E of Caja in hun pakket hebben zitten dus betaal je (nu nog) een behoorlijk bedrag als je zo'n project wilt laten doen, maar ik ben er van overtuigd dat de marktwerking dat nog wel op zal gaan lossen. Er hoeft in de huidige ecconomie maar een detacheerder op te staan die inziet dat high-integrity systemen een markt met potentie is en z'n Java/JavaScript mensen Joe-E/Caja laat leren, en high-integrity wordt heel snel main-stream en voor main-stream prijzen.
Je bedoelt natuurlijk Caja en dat is ook wel eens vulnerable. Dan was digid.nl op 18 september offline gehaald. Waarmee je zo iets ook bouwt, het zal altijd vulnerabilities kennen.Ideaal gezien zou je dit soort systemen eigenlijk from-the-ground-up met Caha of Joe-E willen bouwen. Dat zijn in capability secure versies van de mainstream talen JavaScript en Java die uitermate geschikt zijn om high integrity systemen mee te bouwen.
@pibara: Zelfs als iets alleen maar kwetsbaar is voor FF gebruikers is dat voor een site als digid.nl reden genoeg om hem inderdaad offline te halen,
http://www.thespanner.co.uk/2012/09/18/hacking-caja-part-2/We can now execute any JavaScript and bypass the sandbox because the sandboxed setTimeout function specifically checks for a string type but forgets the array literal.
[Reactie gewijzigd door Jan-E op donderdag 10 januari 2013 14:26]
Heb je die bug zelf wel gelezen man? Dan had hooguit digid dus alleen voor FF gebruikers dicht gemoeten.Dat is m'n hele punt, een systeem zal altijd bugs kennen, maar wat is de impact van die bugs. Zonder o-caps en POLA based design is de impact al heel snel desastreus.
Het is niet de overheid, maar de grote ICT-bedrijven die dat voor de overheid doen, dus je capgemini etc...
Het is inderdaad lachwekkend om te horen dat Brenno de Winter op BNR vertelt dat dit lek voorkomen had kunnen worden, juist omdat het opensource is. Het is onmogelijk om 100% veiligheid te garanderen, ook met code review.
Dat is natuurlijk niet helemaal waar; DigiD is al kwetsbaar geweest zolang het lek in de code heeft gezeten. Dat het lek niet publiek bekend was, wil niet zeggen dat niemand het al eerder gevonden heeft, en misschien wel misbruik van gemaakt heeft.DigiD is in de nacht van dinsdag of woensdag kwetsbaar geweest; de lekken waren toen al bekend, maar DigiD was toen online. Woensdagochtend ging de identificatiedienst offline
Probeer dat maar eens aan het algemene publiek uit te leggen.
Ik zie de nieuws artikelen al.
"DigiD al jaren onveilig, gegevens van alle gebruikers kunnen op straat liggen"
Hoewel feitelijk juist gaat dat politiek gezien natuurlijk weer een heel eigen leven leiden.
Elk systeem is per definitie onveilig, het belangrijkste is welke risico kwalificatie je aan je data geeft en hoe ver je wilt gaan met de beveiling van je data.
Of dat goed gegaan is bij DigiD durf ik geen uitspraken over te doen, maar het is een van de reden waarom ik ook nog steeds erg sceptisch ben over het EPD omdat ik het niet vertrouw dat die analyse daar goed is uitgevoerd.
Ik zie de nieuws artikelen al.
"DigiD al jaren onveilig, gegevens van alle gebruikers kunnen op straat liggen"
Hoewel feitelijk juist gaat dat politiek gezien natuurlijk weer een heel eigen leven leiden.
Elk systeem is per definitie onveilig, het belangrijkste is welke risico kwalificatie je aan je data geeft en hoe ver je wilt gaan met de beveiling van je data.
Of dat goed gegaan is bij DigiD durf ik geen uitspraken over te doen, maar het is een van de reden waarom ik ook nog steeds erg sceptisch ben over het EPD omdat ik het niet vertrouw dat die analyse daar goed is uitgevoerd.
Op dit item kan niet meer gereageerd worden.
Onderwerpen
Populair: Samsung Websites en communities Mobiele telefoons Laptops Sony Games Microsoft Politiek en recht Consoles Microsoft Xbox One
© 1998 - 2013 Tweakers.net B.V. Contact Over Tweakers Jouw privacy Algemene voorwaarden Cookies
Tweakers wordt uitgegeven door De Persgroep en wordt gehost door True
