OV-site lekt Persoonlijke data 168.000 mensen

[LuckY]

Volgens webwereld is de site Ervaar het OV gehacked door een (mogelijk) nederlandse hacker die zichzelf ins3ct3d noemt.



Het bleek hier om een SQL Injection/Insertion te gaan.

Om de FP voor te zijn, kunnen we hier alvast discussiëren.

Echter komt dit niet uit het artikel naar voren:

- Hoort dit bij een landelijke OV diensten of is dit een individuele actie?
- Gaat het om 168.000 mensen uit die provincie of gaat het om een groter gedeelte mensen

Tevens gaat het om de volgende gegevens die uit de database gehaald kunnen worden:

• naam
• adres
• geboortedatum
• e-mailadres
• telefoonnummer

Hier een directe link naar de video

[Prx]

De website is ondertussen 'wegens werkzaamheden tijdelijk niet toegankelijk'. Jammer dat het OV-chipkaart project weer onder vuur komt te liggen.

[_Apache_]

Jammer? Ik ben ervoor dat lekken aangewezen worden en daardoor weggewerkt worden, jammer vind ik het pas als mensen met deze gegevens aan de haal gaan. Want die mensen kunnen er weinig aan doen dat hun gegevens op straat zijn komen te liggen.

[RoadRunner84]

Hopelijk (maar ik vrees vna niet) zal dit een gedeeltelijke terugrol van OV chipkaarten veroorzaken, liefst met intrinsieke anonimiteit, in plaats van de "geef al je bewegingen, gedachten en gesprekken door aan de overheid" insteek van nu.

[beany]

SQL Injection/Insertion

Dat is wel erg sneu... Je mag toch aannemen dat men tegenwoordig dit soort grapjes standaard tegen gaat

[Anoniem: 356260]

Eens met Apache, de gebruikers van de website kunnen er niets aan doen dat hun gegevens toegankelijk zijn voor anderen. Volgens de bron gaat het hier over een website waar je op naam gestelde OV chipkaarten kan bestellen en dat maakt het tot een landelijke kwestie.

[Wiebbe]

Ik zou toch wel verwachten dat voor dit soort website eerst een security specialist er over heen is gegaan met alle normale standaard grapjes. Er zijn technieken die erg geavanceerd zijn en daarom niet zo heel erg vaak voorkomen, maar SQL injection is daar er volgens mij niet een van

Maar het geeft wel aan dat het niet altijd maar koek en ei is zoals iedereen altijd zegt over overheids projecten.. Zal het bij bijvoorbeeld het EPD dan wel goed gaan?

Ik hoop dat dit verhaal een staartje gaat krijgen!

[mux]

Is de informatie 'op straat' komen te liggen danwel verkocht, of heeft de hacker [zoals het hoort] de website op de hoogte gesteld van het lek en de informatie niet openbaar gemaakt?

[Anoniem: 58485]

Hard.

Maar dit betreft aanmeldingen van de OV-chipkaart. Niet OV-chipkaart gegevens zelf

[Grannd]

Dit is de zoveelste klap in het gezicht voor de OV-chipkaart, en zoals Jism hier al zegt heeft dit alleen maar indirect iets met die chipkaart te maken (als je strippenkaarten via die site kon kopen kon precies hetzelfde gebeuren), toch zullen veel mensen dat onderscheid niet maken.

[LuckY]

Anoniem: 58485 schreef op dinsdag 18 mei 2010 @ 08:40:
Hard.

Maar dit betreft aanmeldingen van de OV-chipkaart. Niet OV-chipkaart gegevens zelf

Van die aangemelde gegevens worden chipkaarts gemaakt;) Dus je hebt het over OV-chipkaarten vanuit daar

[HotFix]

LuckY schreef op dinsdag 18 mei 2010 @ 08:49:
[...]

Van die aangemelde gegevens worden chipkaarts gemaakt;) Dus je hebt het over OV-chipkaarten vanuit daar

En sowieso, de gegevens van overheidsinstellingen zijn op straat komen te liggen; not done.
Het is weer ontzettend zwak..

[LuckY]

HotFix schreef op dinsdag 18 mei 2010 @ 08:52:
[...]


En sowieso, de gegevens van overheidsinstellingen zijn op straat komen te liggen; not done.
Het is weer ontzettend zwak..

Dat zeker, maar daarom vroeg ik mij ook af of het een subtak of niet is.
Van de globale OV chipkaart database?

[jbdeiman]

Een persoon heeft in principe maar 1 chipkaart, dus als het de centrale database is, dan zou het logisch zijn (wegens de 1-op-1 relatie) dat de chipkaart-gegevens (of iig het chipkaart-nummer) ook op te halen waren.
Het lijkt er hierdoor meer op dat het een subtak betreft die puur bedoeld is om kaarten aan te kunnen vragen e.d., niet om de cliëntgegevens verder ook op te slaan.

[Jaap-Jan]

Op de radio werd gezegd dat de website is opgezet door Overijssel, Flevoland en Gelderland met als doel om mensen in het OV te krijgen. Laatstgenoemde provincie zou verantwoordelijk zijn voor de site.

Een woordvoerder van de provincie zei wel dat een site nooit 100% waterdicht gemaakt kan worden. Helaas was hij niet zo tech-savvy en had hij zich niet op de hoogte laten stellen hoe het technisch mogelijk was. De oorzaak is volgens mij wel duidelijk, sqlmap is een programma waarmee sql injection attacks kunnen worden uitgevoerd. Helaas dat de verslaggever dat niet wist, dan had hij de woordvoerder aan kunnen vallen dat SQL injection zo'n standaard aanvalsmethode is dat elke websitebouwer zijn site daartegen zou moeten beschermen.

[ Voor 58% gewijzigd door Jaap-Jan op 18-05-2010 09:56 . Reden: Gemeente -> provincie ]

[woekele]

Gemeente Gelderland?

[Jaap-Jan]

Even een kopje koffie halen.

[Eärendil]

Ervaar het OV Privacy Statement
Tijdens uw bezoek aan deze internetsite kunnen de aanbieders van het openbaar vervoer in Gelderland persoonsgegevens over u verzamelen, zowel direct (via een verzoek om gegevens aan u) als indirect. De aanbieders van het openbaar vervoer in Gelderland zullen deze persoonsgegevens uitsluitend aanwenden voor de in dit privacystatement omschreven doeleinden en zullen zich in alle gevallen houden aan de eisen die de Wet Bescherming Persoonsgegevens stelt.

Wet bescherming persoonsgegevens

Artikel 13
De verantwoordelijke legt passende technische en organisatorische maatregelen ten uitvoer om persoonsgegevens te beveiligen tegen verlies of tegen enige vorm van onrechtmatige verwerking. Deze maatregelen garanderen, rekening houdend met de stand van de techniek en de kosten van de tenuitvoerlegging, een passend beveiligingsniveau gelet op de risico's die de verwerking en de aard van te beschermen gegevens met zich meebrengen. De maatregelen zijn er mede op gericht onnodige verzameling en verdere verwerking van persoonsgegevens te voorkomen.

[Kazu]

Het bleek hier om een SQL Injection/Insertion te gaan.

Ik dacht dat we vandaag de dag wel van dit soort grapjes af waren bij grote sites. 'Gelukkig' treft dit niet de database met gegevens van alle OV-chipkaart gebruikers...

[w4rguy]

Blijkbaar id e web developer vergeten zijn ogen open te doen. Als je zo een website bouwt weet je dat de ov chipkaart een gevoelig onderwerp is, zeker op bevweiligingsniveau. Dan zou je als devver moeten weten dat je extra aandacht op de beveiliging moet leggen om te bewijzen dat het wel veilig is. Jammer genoeg is het WEER niet gebeurd...een blunder van formaat!

oh by the way:
piratenpartij, kom er maar inj, want hoe je het wend of keert: zij hadden gelijk.

[Gizzy]

Als je als website developer het niet weet, zou de organisatie het moeten weten wanneer ze zulke gegevens gaan vastleggen. De overheid legt wat betreft het vastleggen en het gebruik van persoonsgegevens strenge eisen op aan het bedrijfsleven en terecht, maar zelf moeten ze daar ook aan voldoen. Helaas lopen er dus mensen binnen de overheid rond, die er niet bij na denken om even een impact / risk analyse los te laten op een dergelijk project of website.

Wat mij betreft laat dit een gebrek aan kennis zien bij de desbetreffende organisatie/gemeente(n) en dan niet een gebrek aan kennis bij 1 persoon, maar een gebrek aan kennis over alle niveaus bij de betrokken partijen. Voor een dergelijk project zullen niet maar 2 ontwikkelaars betrokken zijn geweest.

Als er nu een gecompliceerd aanval was uitgevoerd, had ik misschien nog kunnen denken dat het niet voorkomen had kunnen worden, maar SQL injection kom op, die zijn bijna zo oud als pac man.

[ Voor 13% gewijzigd door Gizzy op 18-05-2010 10:50 ]

[mux]

Tsja... Het is natuurlijk deplorabel dat dit met zoiets simpels als SQL injection is gebeurd maar realistisch gezien is het gros van de websites hiervoor vatbaar, het wordt echter alleen daadwerkelijk gedaan als er iets te halen valt. De websites van grootleveranciers waar ik dagelijks mee werk (elektronica-grootleveranciers) zijn ook stuk voor stuk vatbaar voor injection en XSS.

[Davio]

Ik vind het bijzonder knullig.

Als je met zo'n gevoelig project bezig bent, dan zorg je toch dat de veiligheid tip-top in orde is? Dan huur je gewoon een bureau in met hackers (niet crackers) en zeg je: "Kijk maar of je er doorheen komt."

Ik ben momenteel bezig met een website waarbij veiligheid van essentieel belang is en we nemen allerlei maatregelen om te zorgen dat die veiligheid gewaarborgd is. Zo hebben we de site laten testen door Pricewaterhousecoopers (die hier blijkbaar een afdeling voor hebben) en lig ik regelmatig in de clinch met de projectgever omdat ik erg op de veiligheid let.

Voorbeeld: Bij 3x fout inloggen wordt de gebruiker een tijdje geblokkeerd. Nu hebben wij de optie om het wachtwoord te veranderen waarbij het oude wachtwoord ook moet worden ingevoerd en ik vond het een goed idee om de gebruiker dan ook te blokkeren als daar 3x fout werd ingevoerd. De projectleider vond dit overkill omdat de gebruiker immers al ingelogd is en uiteindelijk hebben we besloten hiervan af te zien.

Nu gaat het niet om de keuze of je dit wel of niet doet, maar meer om de mindset waarmee je bezig moet zijn bij dit soort projecten. Zoals ik tegen de projectleider zei: "Het is beter om het eerst dicht te timmeren en indien gewenst open te gooien dan dat je allerlei lekken moet dichten als je in productie bent."

Ik ben ervan overtuigd dat als de Webdeveloper(s) een simpel PDF'je hadden gelezen over (My)SQL security dat dit niet gebeurd zou zijn.

[Anoniem: 14124]

w4rguy schreef op dinsdag 18 mei 2010 @ 10:41:
Blijkbaar id e web developer vergeten zijn ogen open te doen...

Nee, de overheid heeft hier gefaald. Je kunt van een web developer niet verwachten dat hij bugvrije software oplevert.

Daarom zijn er testprocedures, en is de opdrachtgever altijd verantwoordelijk voor de functionele acceptatie van software. De overheid had hier dus één of meerdere security audits op moeten los laten door gerenomeerde bureaus in Nederland.

Zeker als het hier wederom gaat om een overheidsinstelling met profielinformatie.

Maar zoals het vaak gaat, er is geen budget, het moet snel, en in de aanbesteding is alleen gekeken naar prijsstelling en niet naar kwaliteit en borging van die kwaliteit.

[mux]

Ik kom terug op mijn eerdere statements, overheidswebsites dienen te voldoen aan ISO 27001 en 17799.

[w4rguy]

Anoniem: 14124 schreef op dinsdag 18 mei 2010 @ 11:10:
[...]


Nee, de overheid heeft hier gefaald. Je kunt van een web developer niet verwachten dat hij bugvrije software oplevert.

Daarom zijn er testprocedures, en is de opdrachtgever altijd verantwoordelijk voor de functionele acceptatie van software. De overheid had hier dus één of meerdere security audits op moeten los laten door gerenomeerde bureaus in Nederland.

Zeker als het hier wederom gaat om een overheidsinstelling met profielinformatie.

Maar zoals het vaak gaat, er is geen budget, het moet snel, en in de aanbesteding is alleen gekeken naar prijsstelling en niet naar kwaliteit en borging van die kwaliteit.

kan misschien aan mij liggen hoor ... maar als je een site developed... test je hem toch voor je hem uitgeeft ?

[Anoniem: 14124]

Je test een oplevering altijd, maar developers zijn mensen en het schijnt dat mensen (grote) fouten maken. Sterker nog, je test met behulp van test scripts, test scenario's, en test plannen en ook een test plan kan op zijn beurt fouten bevatten of missende onderdelen die dan niet getest worden.

De developer is niet de eigenaar van de site, dat is de overheid die de verantwoordelijkheid heeft over de data in die site. Ergo, de overheid moet zorgen dat de beveiliging op orde is en wordt geverifieerd door een onafhankelijke partij.

[Jaap-Jan]

Je hebt verschillende niveaus waarop je test, unit testing, user acceptance testing, enzovoort. Het is aan de opdrachtgever om de eisen op tafel te leggen met betrekking tot de beveiliging. De AV geeft aan dat ze voldoen aan de WBP, de opdrachtgever had dus de eis daaraan werd voldaan. Deze richtlijnen kunnen ontwikkelaars dan gebruiken als basis voor hun eigen inschatting over wat het beveiligingsniveau moet zijn.

SQL injection ligt meer bij de ontwikkelaar vind ik. Het is een technisch aspect, daarvan kun je niet verwachten dat de opdrachtgever het naadje van de kous weet.

Functionele eisen liggen inderdaad bij de opdrachtgever, maar dit is geen functionele eis. SQL injection voorkomen is een technische eis.

[w4rguy]

Anoniem: 14124 schreef op dinsdag 18 mei 2010 @ 11:22:
Je test een oplevering altijd, maar developers zijn mensen en het schijnt dat mensen (grote) fouten maken. Sterker nog, je test met behulp van test scripts, test scenario's, en test plannen en ook een test plan kan op zijn beurt fouten bevatten of missende onderdelen die dan niet getest worden.

De developer is niet de eigenaar van de site, dat is de overheid die de verantwoordelijkheid heeft over de data in die site. Ergo, de overheid moet zorgen dat de beveiliging op orde is en wordt geverifieerd door een onafhankelijke partij.

in mijn opinie is de developer degene met de kennis, en niet de overheid dus zou de developer de site veilig moeten maken. Als hij dat niet kan moet hij dat aan andere mensen over laten. De extra kosten daarvoor moeten gewoon in rekening worden gebracht bij de overheid. Als de overheid niet wil betalen? best..dan geen website of je krijgt een onveilige website. Ik denk alleen niet dat die overweging ooit is gemaakt. Als die overweging wel is gemaakt vind ik alsnog dat de developer niet zijn werk goed heeft gedaan, hij zou beter moeten weten.

[Standeman]

Wiebbe schreef op dinsdag 18 mei 2010 @ 08:35:
Ik zou toch wel verwachten dat voor dit soort website eerst een security specialist er over heen is gegaan met alle normale standaard grapjes. Er zijn technieken die erg geavanceerd zijn en daarom niet zo heel erg vaak voorkomen, maar SQL injection is daar er volgens mij niet een van

Maar het geeft wel aan dat het niet altijd maar koek en ei is zoals iedereen altijd zegt over overheids projecten.. Zal het bij bijvoorbeeld het EPD dan wel goed gaan?

Ik hoop dat dit verhaal een staartje gaat krijgen!

Een security specialist? Ik zou bij wijze van spreken een stagair nog een bitch-slap voor geven wanneer ik dergelijk code bij een review zie.

Jaap-Jan schreef op dinsdag 18 mei 2010 @ 11:26:
Je hebt verschillende niveaus waarop je test, unit testing, user acceptance testing, enzovoort. Het is aan de opdrachtgever om de eisen op tafel te leggen met betrekking tot de beveiliging. De AV geeft aan dat ze voldoen aan de WBP, de opdrachtgever had dus de eis daaraan werd voldaan. Deze richtlijnen kunnen ontwikkelaars dan gebruiken als basis voor hun eigen inschatting over wat het beveiligingsniveau moet zijn.

SQL injection ligt meer bij de ontwikkelaar vind ik. Het is een technisch aspect, daarvan kun je niet verwachten dat de opdrachtgever het naadje van de kous weet.

Functionele eisen liggen inderdaad bij de opdrachtgever, maar dit is geen functionele eis. SQL injection voorkomen is een technische eis.

Tja, het kan ook wel eens aan de oprachtgever liggen hoor.

* klant: is het al klaar, we willen eerder live met de website
* devver: nee, er zitten nog problemen in, het is nog niet veilig
* klant: maar werkt de site?
* devver: ja, maar het is nog niet veilig.
* klant: dus website is wel klaar en kan online!
* devver: Nee, hij is nog niet veilig!
* klant: ok, gooi hem maar online. Die veiligheid komt later wel.
* devver: *zucht*

Meestal heb je dan ook nog een manager en een sales-pipo die op de devver staan in te praten om op te leveren.
Zeker als een applicatie ontwikkeld wordt vanuit een snel in elkaar gehacked prototype.

[ Voor 49% gewijzigd door Standeman op 18-05-2010 11:37 ]

[Anoniem: 289377]

w4rguy schreef op dinsdag 18 mei 2010 @ 11:13:
[...]


kan misschien aan mij liggen hoor ... maar als je een site developed... test je hem toch voor je hem uitgeeft ?

Toevallig ben ik dus zo'n "hacker" waar mensen in dit topic het over hebben. Ik test software en netwerken op security holes. Het grootste probleem is 1. gebrek aan kennis bij de developpers. Ja ik verwacht wel dat elke developer weet hoe een SQL injection werkt, maar security is wel een dieper vakgebied dan dit. Als programmeur kun je niet alle security threads bijhouden, dat is ook niet je werk. En 2. als je een applicatie van honderduizend regels code oplevert dan zit daar geheid ergens een fout in. Het is een kat en muisspel welke de developer altijd verliest. Ik hoef maar 1 fout te vinden, en zij moeten het altijd goed hebben. Er glipt altijd wel wat doorheen.

Naar mijn schatting is 80% van alle netwerken/software zo lek als een mandje, 10% kost wat meer moeite en de overige 10% komen we niet doorheen in de tijd welke ervoor gesteld is, dit betekend echter niet dat er niks is.

[w4rguy]

Anoniem: 289377 schreef op dinsdag 18 mei 2010 @ 11:42:
[...]

Toevallig ben ik dus zo'n "hacker" waar mensen in dit topic het over hebben. Ik test software en netwerken op security holes. Het grootste probleem is 1. gebrek aan kennis bij de developpers. Ja ik verwacht wel dat elke developer weet hoe een SQL injection werkt, maar security is wel een dieper vakgebied dan dit. Als programmeur kun je niet alle security threads bijhouden, dat is ook niet je werk. En 2. als je een applicatie van honderduizend regels code oplevert dan zit daar geheid ergens een fout in. Het is een kat en muisspel welke de developer altijd verliest. Ik hoef maar 1 fout te vinden, en zij moeten het altijd goed hebben. Er glipt altijd wel wat doorheen.

Naar mijn schatting is 80% van alle netwerken/software zo lek als een mandje, 10% kost wat meer moeite en de overige 10% komen we niet doorheen in de tijd welke ervoor gesteld is, dit betekend echter niet dat er niks is.

Om met je mee te gaan, ik volg op het moment een opleiding tot particulier digitaal onderzoeker. Ik wil niet zeggen dat ik 'de beste" ben of zo super goed. Maar een SQL injection (heb het filmpje nog niet nader kunnen bekijken welke SQL code hij gebruikt omdat het logischerwijs bij ons op kantoor is geblokkerd). Maar een SQL injection is niet eens zo heel moeilijk tegen te beveiligen. Dat kregen wij op ons 3e jaar MBO. Er blijven altijd fouten in zitten, maar dit had er (naar mijn mening) wel uit gemoeten. Ik noem het daarom een blundert.

**edit**

Het is toch ook je werk om dev-ers op hun fouten te wijzen en net zo lang te zeiken tot ze het wel goed doen/ Het lukt ze waarschijnlijk tog niet, maar als je er niet op hamert gaan ze makkelijker denken.

[ Voor 6% gewijzigd door w4rguy op 18-05-2010 11:50 ]

[Toolskyn]

Standeman schreef op dinsdag 18 mei 2010 @ 11:30:
Tja, het kan ook wel eens aan de oprachtgever liggen hoor.

[...]

Meestal heb je dan ook nog een manager en een sales-pipo die op de devver staan in te praten om op te leveren.
Zeker als een applicatie ontwikkeld wordt vanuit een snel in elkaar gehacked prototype.

Zelfs in een prototype zou ik dit soort extreem basale fouten discutabel vinden. Het is wat mij betreft sowieso al niet logisch om het soort low-level functies te gebruiken waarmee je geen beveiliging tegen SQL injections hebt. Alleen als je een framework aan het maken bent kan ik er nog bijkomen.

Ik geloof in ieder geval geen woord van de reactie van het bedrijf zoals die op de frontpage staat. Het moge duidelijk zijn dat je een reclamebedrijf niet bezig moet laten gaan met dit soort dingen. Laat een reclamebedrijf de vorm doen, dan doet een technisch onderlegd bedrijf wel de techniek.

[LuckY]

Meer Devvers moeten gebruik maken van OWASP maar mee je dus ook voor betaalde aanvallen kan testen.

Echter is het precies zo als standeman schrijft:

* klant: is het al klaar, we willen eerder live met de website
* devver: nee, er zitten nog problemen in, het is nog niet veilig
* klant: maar werkt de site?
* devver: ja, maar het is nog niet veilig.
* klant: dus website is wel klaar en kan online!
* devver: Nee, hij is nog niet veilig!
* klant: ok, gooi hem maar online. Die veiligheid komt later wel.
* devver: *zucht*

Overal in de organisatie awareness zijn
Ik verwacht persoonlijk niet van en developper dat hij alles fixt, maar het is de taak van de project manager of opdrachtgever de code te laten testen door een onafhankelijke partij.
Misschien meerdere, waardoor je de grootste open deuren en ramen richt heb. En dan zeker geen blackbox testing maar whitebox . Waardoor je meer toegang tot de applicatie krijgt om het te testen.

Maar security kost geld en is ongemakkelijk, dus het wordt vaak over het hoofd gezien.
Echter als je een Sue-you cultuur zou krijgen, zou het verandering kunnen brengen, echter of je dat wilt.....

w4rguy schreef op dinsdag 18 mei 2010 @ 11:48:
[...]


Om met je mee te gaan, ik volg op het moment een opleiding tot particulier digitaal onderzoeker. Ik wil niet zeggen dat ik 'de beste" ben of zo super goed. Maar een SQL injection (heb het filmpje nog niet nader kunnen bekijken welke SQL code hij gebruikt omdat het logischerwijs bij ons op kantoor is geblokkerd). Maar een SQL injection is niet eens zo heel moeilijk tegen te beveiligen. Dat kregen wij op ons 3e jaar MBO. Er blijven altijd fouten in zitten, maar dit had er (naar mijn mening) wel uit gemoeten. Ik noem het daarom een blundert.

**edit**

Het is toch ook je werk om dev-ers op hun fouten te wijzen en net zo lang te zeiken tot ze het wel goed doen/ Het lukt ze waarschijnlijk tog niet, maar als je er niet op hamert gaan ze makkelijker denken.

Lekker makkelijk alles op de devver schuiven, maar dat is niet altijd zo. Er komt veel meer bij een project kijken dan code kloppen.
Echter waar het vaak de fout in gaat is bij het begin, in plaats van starten met code kloppen.
Eerst denken waar zitten security error's en waar moet ik dat van te voren afvangen.
Dus dat je aan het begin direct begint met secure code niet achteraf

[ Voor 30% gewijzigd door LuckY op 18-05-2010 11:59 ]

[Jaap-Jan]

[quote]Standeman schreef op dinsdag 18 mei 2010 @ 11:30:
[...]

(...)

Meestal heb je dan ook nog een manager en een sales-pipo die op de devver staan in te praten om op te leveren.
Zeker als een applicatie ontwikkeld wordt vanuit een snel in elkaar gehacked prototype.
[quote=http://robiii.tweakblogs.net/blog/2438/] Dat ben ik, zeker in het geval van SQL injection (en ook XSS) niet met je eens. De quote van RobIII zegt wel genoeg, denk ik:

Veiligheid is niet iets wat je, nadat je (bijna) klaar bent met je site, even "inbouwt" of als nieuwe laag ergens "boven op legt".

Als het gesprek daadwerkelijk zo moet verlopen, dan heeft de developer het werk niet goed gedaan.

En dan ook nog met exploits als dit. Het eerste waar een hacker probeert in te breken op de site zijn via deze bugs, aangevuld met exploits in de server of het cms.

[FunkyTrip]

w4rguy schreef op dinsdag 18 mei 2010 @ 11:13:
kan misschien aan mij liggen hoor ... maar als je een site developed... test je hem toch voor je hem uitgeeft ?

Het is niet de developer die faalt, maar de testafdeling of de product/projectmanager die niet de juiste kundige testers heeft ingehuurd. Die moeten van te voren teststrategieen hebben opgesteld, testrisico's hebben bepaald (samen met de product manager etc). Tenminste, zo doe ik het. Veiligheid had in dit geval een hoog testrisico gehad en zou daardoor extra zwaar getest worden. Testers met ervaring in dit soort projecten zouden dan natuurlijk ook dit soort hackerstesten hebben gedaan.

Echter, waarschijnlijk heeft de testafdeling wel gewoon zijn werk gedaan en in het testadvies vermeld dat de website niet veilig is tegen dit soort aanvallen. En vervolgens is er besloten om toch online te gaan. Zo gaat dat

[ Voor 13% gewijzigd door FunkyTrip op 18-05-2010 12:03 ]

[kenneth]

FunkyTrip schreef op dinsdag 18 mei 2010 @ 12:01:

Het is niet alleen de developer die faalt,

FYP

[Standeman]

Ik bedoelde meer te zeggen dat je als developer nog wel eens een speelbal kan zijn en een beetje rondgeschopt wordt tussen de klant en het management van je eigen bedrijf. De klant wil voor een dubbeltje op de eerste rang zitten en het bedrijf wil zo veel mogelijk verdienen. Hierdoor wordt het soms onmogelijk gemaakt om als developer je werk goed uit te voeren met dergelijke problemen als gevolg.

Het is dus lang niet altijd zo dat developers alle verantwoordelijkheid dragen bij de dergelijke problemen.

[w4rguy]

FunkyTrip schreef op dinsdag 18 mei 2010 @ 12:01:
[...]


Het is niet de developer die faalt, maar de testafdeling of de product/projectmanager die niet de juiste kundige testers heeft ingehuurd. Die moeten van te voren teststrategieen hebben opgesteld, testrisico's hebben bepaald (samen met de product manager etc). Tenminste, zo doe ik het. Veiligheid had in dit geval een hoog testrisico gehad en zou daardoor extra zwaar getest worden. Testers met ervaring in dit soort projecten zouden dan natuurlijk ook dit soort hackerstesten hebben gedaan.

Echter, waarschijnlijk heeft de testafdeling wel gewoon zijn werk gedaan en in het testadvies vermeld dat de website niet veilig is tegen dit soort aanvallen. En vervolgens is er besloten om toch online te gaan. Zo gaat dat

Oke oke, dan heb ik mij verkeerd verwoord. Ik doel dan dus niet alleen op de DEV-er, maar op de ORG die het heeft gedeveloped. degene die dus verantwoordelijk was voor het uitbrengn van de site. Ik bedoel.. dat is hetgene wat Gelderland wil weten denk ik.. want hier gaan zij natuurlijk niet voor betalen (zou ik niet doen in ieder geval).

[Davio]

Je moet ook rekening houden met waar de kennis zit.

Die zit niet bij de provincies, die alleen opdracht geven om de site te maken. De developers horen de kennis te hebben over website security. En als de developers aangeven dat de site klaar is en er zit nog zo'n fout in, dan vind ik dat ze gewoon verantwoordelijk zijn.

[ Voor 3% gewijzigd door Davio op 18-05-2010 12:30 ]

[LuckY]

Davio schreef op dinsdag 18 mei 2010 @ 12:20:
Je moet ook rekening houden met waar de kennis zit.

Die zit niet bij de provincies, die alleen opdracht geven om de site te maken. De developers horen de kennis te security. En als de developers aangeven dat de site klaar is en er zit nog zo'n fout in, dan vind ik dat ze gewoon verantwoordelijk zijn.

* LuckY Maar wat is nu de kans dat iemand dat vind
* LuckY Kans is redelijk aanwezig
* LuckY Volgend jaar als er budget is kijken we er wel naar
* LuckY Is goed, zolang wij niet aansprakelijk worden gehouden

Er moet gewoon publieke awareness komen !

Toevallig is de overheid begonnen met een nieuwe campange:
http://www.nederlandveilig.nl/veiliginternetten/
waar ook een TV comercial bij hoort : http://www.nederlandveili...n/campagne/tv-commercial/

WMV
MOV

Waarover het gaat dat identiteit fraude zo gemaakt is met een paar gegevens, en dat je veilig moet omgaan met de gegevens.
En nu de overheid nog

[Davio]

Toch heeft het weinig zin om de zwarte piet toe te spelen als we niet precies weten hoe het tijdens de oplevering is gegaan.

Ik vind echter wel dat developers een bepaalde verantwoordelijkheid hebben over het product dat ze maken. Het vervelende is ook dat de afnemer niet snel kan zien of het product helemaal klopt. Als je bij de bakker een heel brood bestelt en je krijgt een halve, dan zie je dat het niet klopt. Hier is dat anders.

Als de provincie een site bestelt die bijna vanzelfsprekend veilig moet zijn en hij is dat niet, dan mogen ze best verhaal halen.

[LuckY]

Davio schreef op dinsdag 18 mei 2010 @ 12:33:
Toch heeft het weinig zin om de zwarte piet toe te spelen als we niet precies weten hoe het tijdens de oplevering is gegaan.

Ik vind echter wel dat developers een bepaalde verantwoordelijkheid hebben over het product dat ze maken. Het vervelende is ook dat de afnemer niet snel kan zien of het product helemaal klopt. Als je bij de bakker een heel brood bestelt en je krijgt een halve, dan zie je dat het niet klopt. Hier is dat anders.

Als de provincie een site bestelt die bijna vanzelfsprekend veilig moet zijn en hij is dat niet, dan mogen ze best verhaal halen.

Maar daar ga je de fout in met je vergelijking, wat als je een brood koopt die er perfect uitziet, perfect smaakt, maar waar sporen van noten in zitten.
99% heeft er geen last van en hoeft het niet te weten... maar die 1% die het wel merkt treft de gevolgen.
Daarom denk ik dat het goed is om vooraf te waarschuwen...
kon-snel-geen-andere-vergelijking-verzinnen

[Gizzy]

ssj3gohan schreef op dinsdag 18 mei 2010 @ 10:51:
Tsja... Het is natuurlijk deplorabel dat dit met zoiets simpels als SQL injection is gebeurd maar realistisch gezien is het gros van de websites hiervoor vatbaar, het wordt echter alleen daadwerkelijk gedaan als er iets te halen valt. De websites van grootleveranciers waar ik dagelijks mee werk (elektronica-grootleveranciers) zijn ook stuk voor stuk vatbaar voor injection en XSS.

En daar heb je in ieder geval dan ook melding van gemaakt bij die partij? Lijkt me wel zo goed om te doen, soms hebben ze er gewoon geen erg in. Soms is het niet nodig om het verkomen, dat kan ook.

[Davio]

LuckY schreef op dinsdag 18 mei 2010 @ 12:47:
[...]

Maar daar ga je de fout in met je vergelijking, wat als je een brood koopt die er perfect uitziet, perfect smaakt, maar waar sporen van noten in zitten.
99% heeft er geen last van en hoeft het niet te weten... maar die 1% die het wel merkt treft de gevolgen.
Daarom denk ik dat het goed is om vooraf te waarschuwen...
kon-snel-geen-andere-vergelijking-verzinnen

Maar SQL-injection is niet bepaald nieuw of cutting edge hacken. Daarom had deze fout makkelijk gevonden kunnen en moeten worden.

[mux]

@gizzy Ehm, nou, dat is een hele leuke vraag. De injection vulnerability heb ik aangegeven, maar niks op gehoord. Ik weet ook niet hoever je ermee kunt gaan, ik kwam er per ongeluk achter, zie ook het volgende.

Het XSS-gedeelte is voor zover ik kan overzien niet in hun nadeel, het is alleen een beetje lelijk. Je kunt er geen schade mee doen want vanaf het punt dat je met persoons- en betalingsgegevens gaat werken zit je op een beveiligde, gevalideerde verbinding. Het gaat puur om de catalogus zelf die niet oplet waar zijn requests vandaan komen.

[Bor]

Anoniem: 58485 schreef op dinsdag 18 mei 2010 @ 08:40:
Hard.

Maar dit betreft aanmeldingen van de OV-chipkaart. Niet OV-chipkaart gegevens zelf

Dat is toch een schakel uit de keten waardoor het imago van de OV chipkaart wederom een behoorlijke deuk oploopt.

[j0rDy]

LuckY schreef op dinsdag 18 mei 2010 @ 12:47:
[...]

Maar daar ga je de fout in met je vergelijking, wat als je een brood koopt die er perfect uitziet, perfect smaakt, maar waar sporen van noten in zitten.
99% heeft er geen last van en hoeft het niet te weten... maar die 1% die het wel merkt treft de gevolgen.
Daarom denk ik dat het goed is om vooraf te waarschuwen...
kon-snel-geen-andere-vergelijking-verzinnen

ik denk niet dat het hier om percentages gaat. het lek is aanwezig en kan geexploiteerd worden. dit is genoeg reden om een site MITS er een security audit is gedaan niet online te laten gaan (gezien de kosten die met dit project gemoeid zijn ga ik er maar even vanuit dat dit het geval is). je kan er de donder op zeggen dat na alle media aandacht EPD en het OV heeft gekregen op het gebied van security dat het risico van deze applicatie minstens zo groot is als van voorgaande projecten van de overheid. persoonlijk vind ik het uitstekend dat dit naar buiten gebracht word, echter had dit misschien wat tactischer aangepakt kunnen worden? ik ben persoonlijk meer van de white hat oplossingen en dat is de organisatie eerst in te lichten, de gelegenheid te geven het probleem op te lossen en vervolgens het naar buiten te brengen. echter is het effect van deze methode natuurlijk veel groter wat de gehele situatie weer ten goede komt...

[LuckY]

j0rDy schreef op woensdag 19 mei 2010 @ 20:40:
[...]


ik denk niet dat het hier om percentages gaat. het lek is aanwezig en kan geexploiteerd worden. dit is genoeg reden om een site MITS er een security audit is gedaan niet online te laten gaan (gezien de kosten die met dit project gemoeid zijn ga ik er maar even vanuit dat dit het geval is). je kan er de donder op zeggen dat na alle media aandacht EPD en het OV heeft gekregen op het gebied van security dat het risico van deze applicatie minstens zo groot is als van voorgaande projecten van de overheid. persoonlijk vind ik het uitstekend dat dit naar buiten gebracht word, echter had dit misschien wat tactischer aangepakt kunnen worden? ik ben persoonlijk meer van de white hat oplossingen en dat is de organisatie eerst in te lichten, de gelegenheid te geven het probleem op te lossen en vervolgens het naar buiten te brengen. echter is het effect van deze methode natuurlijk veel groter wat de gehele situatie weer ten goede komt...

Ik weet het niet, ik ben het volkomen met je eens dat een project niet gelaunched kan worden voordat het secure is. Echter zoals als vaak is aangeduid wordt er niet veel omgegeven door managers en eigenaren. Ik denk gewoon dat mochten ze het geweten hebben dat er een risico analyse is gedaan en besloten is dat het goedkoper is om wat slechte publiciteit te hebben.

Want wie praat er nu nog over, wat zie je ervan in het nieuws. Jan alleman die heeft zo iets van ja jammer, De nuchtere hollander boeit het niet.

En dat weten project managers ook

[Eärendil]

j0rDy schreef op woensdag 19 mei 2010 @ 20:40:
dit is genoeg reden om een site MITS er een security audit is gedaan niet online te laten gaan

offtopic:
Ook als je MITS met hoofdletters schrijft is het nog steeds niet het woord wat je bedoelt je deze zint, jij bedoelt tenzij

[kenneth]

Misschien zat daar de fout wel ... een of andere hoge pipo bij die OV-site zei:

de site mag niet online mits er een security audit is gedaan.

Dus een uitvoerende heeft de security audit gecanceld en de site online gegooid ...

Je weet maar nooit.