Tja dat doen die waterleidingdsbedrijven ook waar je meterstanden kan opgeven op een website.

Een beveiliging van lik me vestje.

En intussen staan je gegevens naam, adres en meterstanden onder vuur van allerlei malware.


Je moet er toch niet aan denken dat je waterstand gebruik ineens zoveel kubieke meter extra is geworden....en je daar de rekening van krijgt.

Net even gekeken, ze hebben ook nog eens last van een Cross Site Scripting lek...

hier hetzelfde;
Ik heb al vaker contact met (grote) bedrijven gehad die geen ssl aanbieden maar het maakt ze helemaal niets uit !

ander voorbeeld;
ik ben al jaren geen klant meer van een bedrijf (dochter van eneco) maar krijg, na 5 jaar, wel een folder toegestuurd dat mijn gegevens nu online staan en da`s makkelijk als ik een afspraak wil maken.

even gebeld;
Dit kan niet verwijderd worden ivm de belasting etc, etc
maar eh, ik vraag daar toch niet om ?? niets aan te doen mijnheer.
schande !!! AARGH


wat ik zelf ook krom vindt;
ik boek online MET ssl bij een (groot) vakantiepark en vul verplicht al mijn gegevens in.
vervolgens krijg ik een plain tekst mail terug met daarin ALLE door mij in gevulde gegevens...
probeer dat maar eens uit te leggen aan zo`n helpdesk "dame".

Dit is toch geen nieuws? Ik kom zo vaak websites tegen die dit niet hebben.

Wat ik laatst nog tegen kwam was de website van 'radar', die op komt voor consumenten en dergelijke.

Die hebben dit ook niet, wanneer je je aanmeldt. En ze vragen wel om allerlei persoonlijke gegevens..

Hmm, als je dit zelf hebt uitgezocht, dan kan het maar zo zijn dat het illegaal was. Of was je niet vergeten toestemming te vragen?

Mag ik opmerken dat de site van het bedrijfje van Dennis Baaten zelf ook geen geldig SSL-certificaat heeft? Beetje hypocriete en domme actie van hem.

Daarnaast is het nog meer zeer de vraag of SSL een vereiste is voor WBP. De enige manier om persoonsgegevens te achterhalen is door een man-in-the-middle-attack, wat alleen mogelijk is bij een zwakke beveiliging bij de eindgebruiker. Het is niet zo zwart-wit dat je kunt stellen dat de website hiervoor verantwoordelijk is.

Ook wil ik opmerken dat de meeste websites geen SSL gebruiken voor een inloggedeelte, maar alleen voor betalingen en dat soort extreem gevoelige gegevens. Beetje raar om specifiek deze vakantieveilingen-website hierop aan te vallen.

Na ja, waar maken we ons druk om? Maar ik snap het wel hoor.
Ze kunnen straks wel SSL gaan gebruiken, maar als de rest van het systeem niet up-to-date is dan kunnen gegevens ook naar buiten lekken. Dus SSL is niet perse een goede beveiliging, maar wel een klein begin.

Eenmaal een worm, keylogger of trojan op het systeem en weg is je hele beveiliging, en ook dan kunnen gegevens naar
buiten lekken.

Persoonlijk vind ik dat meer overheids instellingen over moeten naar bijv Linux, wat dat O.S. is toch een heel stuk veiliger
en minder vatbaar voor spyware, malware, en andere dreigingen.


Hmmm dus wat leren we hieruit?

Goede zaak dat hier wederom weer aandacht aan wordt besteed, dit geldt echter niet alleen voor vakantieveilingen, maar voor ALLE websites waar je gegevens achter kan laten. Overigens had meneer Baaten wel iets verder mogen kijken, want er draait wel degelijk een COMODO certificaat op de server sinds 1 oktober 2010 zo te zien, maar die lijkt niet correct te zijn geïnstalleerd door Emesa. Overigens kan je gewoon een klacht indienen bij deze club, is dat ook gedaan? http://www.vakantieveilingen.nl/klacht.php

Uhh ik weet niet of het hier om dezelfde "Dennis Baaten" gaat (*), zo ja dan is dit wel een gevalletje pot-verwijt-de-ketel...

Als ik namelijk van de "secure" webmail functie van Traxotic.net (https://secure.traxotic.net/mail.php) gebruik zou willen maken, moet ik kennelijk vanaf http://www.traxotic.net/support/ssl.php, via deze unsecured URL: http://www.traxotic.net/ca.crt, een self-signed certificate downloaden en aan m'n browser toevoegen?!?!

Die download vindt net zo insecure plaats als het bezoeken van vakantieveilingen.nl, een aanvaller kan mij dus een spoofed certificate onder de neus duwen (het minste dat de heer Baten had kunnen doen is een PGP signature toevoegen, hoewel -toegegeven- maar weinig mensen weten hoe je dat vervolgens controleert).
Sterker, een slimme aanvaller zou me zelfs een vals root certificate kunnen aansmeren, een leek zal wellicht niet doorhebben dat het niet om een gewoon certificaat gaat!
N.b. tegen 11 nov. a.s. krijgen aanvallers een nieuwe kans, want dan verloopt het huidige certificaat; alle gebruikers van traxotic webmail zullen dus een nieuw certificaat moeten downloaden...

Beter was het als Dennis Baaten gewoon een commercieel certificaat gekocht had, zijn woorden:(*) Het lijkt hier wel heel erg om dezelfde "Dennis Baaten" te gaan, het Redactie artikel verwijst naar http://www.dennisbaaten.com/2010/10/22/vakantieveilingen-nl-voldoet-niet-aan-wbp/; zowel www.dennisbaaten.com als www.traxotic.net hebben 82.95.168.14 als IP-adres...

Ook begrijp ik de ophef over specifiek vakantieveilingen.nl niet, er zijn zat websites waar je gevraagd wordt persoonlijke gegevens in te vullen zonder dat je daarbij gewezen word op de mogelijkheid om via SSL in te loggen.

Los van dit alles, SSL/TLS aanvallen komen, vermoed ik, in de praktijk extreem veel minder vaak voor dan dat websites zelf gekraakt worden (of dat de PC van gebruikers zelf gecompromitteerd is). Persoonlijk vind ik het niet bieden van SSL/TLS voor logon niet verstandig, maar v.w.b. "het schenden van het WBP" maak ik me veel meer zorgen over lekke web applicaties (denk bijv. aan SQL injecties), XSS attacks (zoals Rajaat hierboven meldde) en slecht geconfigureerde en niet-up-to-date webservers en beheertools.

@Unit10: lees de laatste alinea van het artikel. Dennis heeft geconstateerd dat het certificaat er is en spreek van een configuratiefout.

@Bitwiper: Het gaat inderdaad om dezelfde Dennis. Staat gewoon op zijn blog: http://www.dennisbaaten.com/over/. Verder jammer dat je appels met peren vergelijkt.

Er is namelijk een verschil tussen hobby-hosting en een serieus bedrijf met duizenden klanten. Zoals op traxotic.net staat: "All services offered by Traxotic Networking are exclusively intended for friends and acquaintances of the owner and Linux enthusiast Dennis Baaten, and can best be seen as the result of serious hobbyism.". Gewoon een thuisservertje waar een aantal mensen gebruik van maken dus. Daar kun je inderdaad een certificaat voor kopen, maar je kunt het ook zelf regelen omdat dat dan dus onderdeel van de hobby is.

Bovendien gaat het hier meer om het feit dat het gebruik van een SSL verbinding niet wordt afgedwongen, terwijl je wel wettelijk verplicht bent maatregelen te nemen bij het verwerken van persoonsgegevens. Het feit dat SSL is te hacken of een certificaat is te vervalsen staat hier los van. Wat dat betreft heeft traxotic het beter voor elkaar, want de webmail is alleen te benaderen via https. Dus dat pot-verwijt-de-ketel zie ik niet helemaal. Zoals je hier kunt lezen: http://www.dennisbaaten.com/2008/12/15/helemaal-into-ssl/ heeft Dennis voor alle "secure" webservices een subdomein opgezet, en heeft hij een self-signed root certificaat waarmee hij vervolgens andere certificaten ondertekent.

Ik denk dat het goed is dat er kritisch naar zulke dingen worden gekeken. Dit soort dingen gaan nog te vaak te onveilig.

... kasboek.nl was laatst ook al plat ...
http://www.vakantieveilingen.nl/inloggen.php/%27%3E%3Cscript%3Ealert%28%27xss%27%29%3C/script%3E

Na ja, waar maken we ons druk om? Maar ik snap het wel hoor.
Ze kunnen straks wel SSL gaan gebruiken, maar als de rest van het systeem niet up-to-date is dan kunnen gegevens ook naar buiten lekken. Dus SSL is niet perse een goede beveiliging, maar wel een klein begin.

Eenmaal een worm, keylogger of trojan op het systeem en weg is je hele beveiliging, en ook dan kunnen gegevens naar
buiten lekken.

Persoonlijk vind ik dat meer overheids instellingen over moeten naar bijv Linux, wat dat O.S. is toch een heel stuk veiliger
en minder vatbaar voor spyware, malware, en andere dreigingen.


Hmmm dus wat leren we hieruit?

De ergste vorm van niet gebruik van SSL die ik tot nu ben tegen gekomen is de websites van een aantal woningbouwcorporaties. Hier moet de gebruiker precies die combinatie van gegevens invullen die interessant zijn voor een identiteitsfraudeur: naam, huidige adres, inkomen, rekeningnummer, BSN. Inloggen en gegevens bekijken/wijzigen gaat zonder SSL. Het ergste is dat als men een woning wil zoeken bij die corporaties, men de gegevens in MOET vullen. Je zou denken dat je ook naar het kantoor kan gaan en daar e.a. opgeven, maar vervolgens vult daar de medewerker de gegevens op exact dezelfde onversleutelde pagina in.
Verbazingwekkend genoeg bleken in de betreffende gemeente ALLE corporaties dezelfde fout te maken. Ofwel, men kan geen woning zoeken zonder risico te lopen op identiteitsfraude. Ik heb alle betreffende corporaties aangeschreven en van slechts één een reactie gekregen, namelijk dat men bezig was aan een nieuw systeem en dat men mijn opmerking bij de ontwikkeling daarvan zou meenemen. Verwachte introductie: half jaar later. Na een mail terug dat dit onacceptabel is, bleef het stil. Alle andere corporaties bleven geheel stil. Volgende stap zou klacht bij CBP zijn, maar vraag me af of dit helpt.

Ik ben benieuwd hoe het met corporaties in andere gemeenten is. Misschien iets voor security.nl of BOF om hier eens wat groter onderzoekje aan te wijden?

Vooropgesteld: we maken allemaal fouten (ik in elk geval wel). Ik hoop op een professionele reactie van Dennis Baaten in de trant van "hee, dat kan beter". Niemand is gebaat bij de gebruikelijke argumenten waarom e.e.a. nu niet goed geregeld is. Feit is dat Dennis op deze manier een enorm zwakke schakel introduceert, ook al gaat het mogelijk maar om een beperkt aantal "klanten". En wie kaatst, kan de bal verwachten (ook van anderen zoals in dit geval).

Als het inderdaad zo is dat er maar een paar mensen van z'n secure webmail gebruik maken (op een overigens prachtige website die anders doet vermoeden dan een service voor wat vrienden en kennissen) heb ik nog een tip voor Dennis: schrijf op die certificaat-download page erbij dat men na het downloaden daarvan Dennis even moeten bellen (geen telefoonnummer vermelden!) waarna de gebruiker de hash in het certificaat aan Dennis kan voorlezen ter verificatie. Leg daarbij uit waarom dit noodzakelijk is en waarom men *nooit* zomaar, zonder enige verificatie, certificaten aan webbrowsers zou moeten toevoegen (je leert gebruikers zo de verkeerde dingen). Als Dennis meent kritiek to moeten uitoefenen op anderen op het gebied van enryptie, SSL/TLS etc, zou hij moeten weten waarom.

@Bitwiper: Je hebt zeker een punt; daar zit ruimte voor verbetering. En dat is ook zeker iets wat ik (Dennis) ga aanpassen. En ja, ik weet inderdaad waarom. :-) Ben verder wel positief verrast dat er kritisch wordt gekeken of iemand ook het principe "practice what you preach" toepast. Maar ik geef me natuurlijk niet zomaar 'gewonnen'. Haha. Anyway, point taken. Wordt verbeterd.

De huidige website biedt inderdaad geen SSL ondersteuning. We beschikken al langere tijd over een SSL certificaat maar hebben besloten deze niet meer voor de huidige website te implementeren ivm. de vele aanpassingen die we zouden moeten doorvoeren om beveiligde content van niet beveiligde content te scheiden. We focussen de aandacht nu volledig op de introductie van een geheel vernieuwde site met vele verbeteringen, waaronder beveiliging. We verwachten over een aantal weken deze geheel vernieuwde website te launcheren waarin SSL beveiliging integraal is opgenomen.

Gaarne tot nadere toelichting bereid,
André Buren, CTO Vakantieveilingen.nl

Dat zou zo maar eens kunnen inderdaad, maar ethiek is nou niet echt mijn ding. En als je iedereen toestemming moet vragen om te kijken of hun spul brak is zouden er weinig security incidenten zijn, omdat ze dan per definitie toch geen toestemming geven. Bovendien, er is niets in de site aangepast, ik heb nergens ingebroken, het is enkel een gefabriceerde link met html er in. Aangezien vakantieveilingen.nl toch de gehele site gaat vernieuwen lijkt me dit ook geen prioriteit.

Toppie!

Het is helemaal niet nodig om die beide types content te scheiden. Als je alles beveiligd doet, kun je ook niet de fout maken om een pagina die beveiligd moet worden over het hoofd te zien en onbeveiligd aan te bieden.

Peter

Dit klinkt een beetje als een hobbyist met een tekort aan aandacht. Natuurlijk moet zo'n site wel een dergelijk eenvoudige maatregel implementeren, maar het is nou ook weer niet zo dat de gegevens hierdoor meteen op straat liggen. Met de hierboven genoemde cross site scripting problemen heb je als kwaadwillende meer kans om vertrouwelijke informatie te achterhalen. Of gaat Dennis nu even voordoen hoe hij nu dataverkeer heeft kunnen onderscheppen?

Eerder een hobbyist met een teveel aan vrije tijd. Ik heb die XSS trouwens hier niet gepost, ik heb enkel gemeld dat ie er is, zonder verwijzing naar een pagina. Die hier eerder geposte link is niet van mij.

Edit: gelukkig leest vakantieveilingen.nl dit ook en hoop dat ze er met de bouw van de nieuwe site rekening mee houden.
Edit2: ik zal vakantieveilingen.nl wel even via email inlichten met een link, is misschien wel zo netjes. Als ik nou ergens op de site kon vinden waar ik naar toe kan mailen...
Edit3: vakantieveilingen.nl is op de hoogte gebracht.
Edit4: te vroeg gejuigd, ze hebben me een niet-werkend email adres gegeven :(
Edit5: nu zou het geregeld moeten zijn

In de meeste gevallen zijn websites niet geoptimaliseerd op benodigde bandbreedte en vooral niet op het aantal gebruikte verbidningen per page-view. Als je een druk bezochte site hebt (vooral als je pieken verwacht of niet kunt uitsluiten) heb je te maken met een flink prijskaartje, ofwel door er brute force performance tegenaan te gooien, ofwel door de site zelf te optimaliseren. Vooral dat laatste kost ook nog eens veel tijd.

Overigens is het probleem zelden de symmetrische encryptie, maar de benodigde handshake met bijbehorende assymetrische encryptie berekeningen (per TCP connectie, en dat kunnen er velen zijn per page view).

Bijkomend feit: Microsoft en Mozilla hebben Certificate Authorities gevraagd om per 2011-01-01 geen certificaten met een public key size kleiner dan 2028 bits te ondertekenen (momenteel zijn certs met een key van 1024 bits nog gebruikelijk, en dat is ook de lengte die je krijgt als je openssl gebruikt met de default meegeleverde openssl.cnf, d.w.z. zonder expliciet om een langere sleutel te vragen; zie ook http://bugs.debian.org/487152). Een interessante discussie hierover is te vinden vanaf dit bericht: http://www.mail-archive.com/cryptography@metzdowd.com/index.html#11846. In http://www.mail-archive.com/cryptography@metzdowd.com/msg11851.html merkt Steven Bellovin op: De volgende PDF presentatie (die ik na even googlen vond) biedt een overzicht van de mogelijkheden (maar gaat niet in op de economische aspecten):http://assets.en.oreilly.com/1/event/22/High%20Performance,%20Low%20Cost,%20and%20Strong%20Security_%20Pick%20Any%20Three%20Presentation.pdf

Een bekend voorbeeld is deze blog waarin wordt toegelicht hoe men bij gmail e.e.a. heeft aangepakt: http://gmailblog.blogspot.com/2008/05/need-for-speed-path-to-faster-loading.html.

Overigens erg goed dat André Buren aankondigt dat er verbeteringen aan de website vakantieveilingen.nl zullen worden doorgevoerd. Hopelijk ligt de focus daarbij niet uitsluitend op de verbindingen maar is er ook aandacht voor de bescherming van (persoons) gegevens "in "de site zelf. N.b. op de website van de "Paymenty Card Industry" https://www.pcisecuritystandards.org/ kun je prima richtlijnen vinden die beschrijven waar het geheel aan zou moeten voldoen.

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.

Helaas moet ik gebaseerd op het bovenstaande opmaken dat men MISSCHIEN handelt in strijd met de wet. Het is mogelijk om gebruikersnamen en wachtwoorden door middel van onderschepping van ip verkeer deze data te bemachtigen en voor een kwaadwillend persoon andere personen te benadelen. Ik wil daar wel graag een kanttekening bij maken. Ik moet de eerste persoon nog tegenkomen die dat ip verkeer kan onderscheppen.

Hoe doe je dit?
Door een bot of virus op de pc van de gebruiker te installeren die dat ip verkeer onderschept en naar bijv. de kwaadwillende gebruiker stuurt. Zijn jullie deze al tegen gekomen?
Inderdaad door Cross Site Scripting ... Maar de gebruiker zal dus eerst op een link moeten klikken in een email om naar vakantieveilingen.nl doorgestuurd te worden waarna er gebruik gemaakt kan worden van de exploit.
Mijn punt is dat de gebruiker ook verantwoordelijkheid heeft ten aanzien van zijn of haar persoonsgegevens alsmede de aanbieder.

Dit zijn gevallen waar de gebruiker ook verantwoordelijkheid heeft. Niet zomaar op emails klikken waarvan je de afzender niet kent.

Ok, ik weet al wat jullie gaan zeggen. Gebruikersnamen en wachtwoorden mogen niet in plain text verzonden worden. Dat klopt. Het punt wat ik wil maken is dat geen van jullie in staat is om in de database van vakantieveilingen.nl kan "neuzen". Het is NIET mogelijk om een kopie van deze database te maken. Wat wel mogelijk is om d.m.v (en dan val ik in herhaling) op de client client-side software te installeren om gebruikersnamen en wachtwoorden te bemachtigen. Maar dat geldt voor alle websites. Rabobank.nl, ing.nl e.d. en dan per 1 gebruiker.

Ik vindt dit artikel een beetje overtrokken en misschien kan Dennis Baaten nog even aanhalen welke gevaren er nu precies aanwezig zijn. In de wet staat ook dat je niemand vals mag beschuldigen, dat heet smaad.

Smaad is het opzettelijk zwartmaken van een ander door deze in het openbaar van feiten te beschuldigen waaraan hij of zij zich schuldig zou hebben gemaakt, zonder dat wordt gehandeld uit noodzakelijke verdediging. Het doel is het aantasten van iemands reputatie of goede naam. De aantasting kan mondeling, bij schrift of bij afbeelding plaatsvinden. Deze laatste varianten vallen onder het begrip smaadschrift.

Ik begrijp wel wat je nu denkt....huh? Smaad? Uitgaand van het artikel zie ik geen enig bewijs dat men bij vakantieveilingen.nl een fout heeft gemaakt, tenzij je anders bewijst. Waar hebben we het over? een SSL certificaat. lol

Met vriendelijke groet,

vvsniper

P.S.: Nee, ik werk niet voor die gasten, en ben geenszins verbonden aan hen.

Besef ik nu pas.hehhe

JURISPRUDENTIE