Database gaf honderdduizenden afbeeldingen van fotohokjes vrij door lek

Databases waar de afbeeldingen en e-mailadressen in terechtkwamen van fotohokjes met greenscreentechniek, waren door een sql-injectie te benaderen. Onder andere waren foto's van bezoekers van de Apenheul in te zien.

Maarten Hartsuijker van beveiligingsbedrijf Classity kwam het lek van de namen, e-mailadressen en foto's op het spoor na een eigen bezoek aan de Apenheul. Hij nam een foto in het FotoHotShot-hokje van het dierenpark en kreeg een e-mail met een link naar een site waar de foto stond.

"Er ging iets mis bij het openen waarop ik naar de broncode keek en direct zag dat er van zwakke code gebruikgemaakt werd", vertelt Hartsuijker aan Tweakers. Onder andere trof hij de mogelijkheid tot sql-injectie aan. Zodoende kon hij de database met foto's en andere gegevens benaderen. "Het was veel breder dan alleen de Apenheul. Ik kon bij 25 databases van andere bedrijven", beschrijft de onderzoeker, die benadrukt dat hij de databases niet binnengehaald heeft. Volgens hem waren er 500.000 entries in de database en stonden er gegevens vanaf 2015 in, al waren afbeeldingen uit die tijd wel verwijderd.

Hij nam contact op met de Apenheul en Bitmove, het bedrijf dat de fotohokjes ontwikkeld heeft. Na enkele pogingen slaagde een ontwikkelaar in opdracht van Bitmove erin het sql-lek te dichten en inmiddels zijn er meer beveiligingsmaatregelen doorgevoerd. Naast de Apenheul werden de greenscreen-installaties van Bitmove gebruikt door onder meer een brouwerij, waarschijnlijk Heineken, en een voetbalclub. Volgens Bitmove zijn er in vijf maanden tijd bijna 60.000 foto's bij de hokjes in de Apenheul gemaakt en meer dan 15.000 opt-in e-mailadressen verzameld.

Reacties (214)

Er zijn hier twee levensgrote problemen:

1) Hoe krijg je het bij bedrijven tussen de oren dat ze serieus naar beveiliging moeten kijken?
Een ander artikel van vandaag bericht over de vrij makkelijk toegankelijke zonnepanelen, en zo'n beetje elke dag wordt duidelijk dat anno 2017 nog steeds producten worden gemaakt met non-https adminpagina's, al dan niet via een niet versleuteld (en soms niet eens te versleutelen door een instelling) wifinetwerk met simpele initiele wachtwoorden die nog eens overal hetzelfde zijn (en soms zelfs een zelfde superadminpassword bevatten!!!). Onvoorstelbaar. Alsof er nog nooit iets is gehacked. En bedrijven ondernemen pas actie als er een keer iets op TV geweest is of in de Telegraaf. Ze willen dus gewoon bewust de moeite niet nemen omdat het a)teveel tijd/geld kost en b)het voor de gebruikt 'te moeilijk' zou zijn en dus zou afschrikken. Doet me denken aan de introductie van de veiligheidsgordel. Autofabrikanten wilden dat niet (!) omdat je dan feitelijk zei dat een auto een gevaarlijk ding is waarin je dood kunt gaan. Dat is geen leuk commercieel verhaal vonden ze. Inmiddels heeft Volvo er zijn USP van gemaakt...
En dat brengt me op het tweede punt:

2)Jan Publiek snapt nog steeds het belang van een goede beveiliging niet.
Het wil maar niet lukken. Zelfs in mijn eigen omgeving krijg ik meewarige 'daar heb je die nerd weer' blikken als ik probeer te hameren op veilige wachtwoorden, een goede beveiliging van wifi en hun mobiele telefoons. "Ik ben toch niet interessant" zeggen ze dan. Zich niet realiserend dat hun mobiel bv een schat aan informatie bevat en - belangrijker nog - waarschijnlijk ook toegang geeft tot allerlei platforms die met financien te maken hebben. Of in ieder geval misdadigers op het juiste spoor zet van waar dat te vinden zou zijn. Mét voldoende info om je wachtwoord te raden of gewoon uit je mobiel te vissen.

Wie weet hoe we dat voor elkaar krijgen mag het zeggen. Het eerste denk ik alleen maar door hele hoge (en dan bedoel ik ook écht hoge) boetes, naming en shaming en de verplichting alle apparaten kostenloos te herstellen. bedrijven pak je namelijk alleen maar met een financiele prikkel.

Hoe je Jan Publiek zover krijgt weet ik niet. Ik heb al een keer een aardige poging gezien op televisie in de vorm van een show waarin men van alles liet zien met uitleg enzo. Maar ja...weer op Ned3 geloof ik en op een onchristelijk tijdstip. Programmeer zoiets op primetime. Het is een onderwerp van nationaal belang. Ik durf zelfs aan dat het kan helpen met terreurbestrijding. Immers, terroristen kunnen jouw zakke wifi netwerk kraken om internet toegang te krijgen die écht annoniem is voor hen. Lekker via hun vpn oid over jouw netwerk surfen en hun communicatie doen. Staat het AT bij jou aan je bed. Dat verhaal vertel ik altijd als mensen zich afvragen waarom hun wifi zo goed beschermd moet zijn. Of een pedo die zijn kinderporno verspreid via een ander AP. Ik kan bv ook de wifi van de buren hacken als ik mijn torrents wil seeden. Lekker...krijgen zij een brief van BREIN...
Dat zijn allemaal dingen die men zich niet realiseert.
Maar het zal moeilijk blijven. Zolang er nog een categorie mensen is die meent te kunnen spelen met hun telefoon en autorijden tegelijk heb ik weinig hoop op begrip voor een goede online beveiliging...

Het probleem is in mijn ogen vaak dat iedereen elkaars handje boven het hoofd houdt en er uit eindelijk niemand voor verantwoordelijk wordt gehouden, terwijl de situatie moet zijn dat alle partijen verantwoordelijk worden gehouden.

Dat betekent inderdaad boetes voor de IT bedrijven, maar ook de Apenheul zou verantwoordelijk moeten worden gehouden en daarnaast uit eigen beweging die hokjes uit het park moeten gooien.

Nu krijg je deze eindeloze smoesjes weer
- Apenheul zegt het te hebben uitbesteed
- Developers zeggen het te hebben aangekaart, maar dat management verkeerde prioriteiten stelde
- Management zegt dat er niet genoeg budget was vanuit de klant

Zo kaatst iedereen de bal eventjes en loopt het met een sisser af.

Misschien zou er een database gebouwd moeten worden waar IT bedrijven die de fout in zijn gegaan in gezet kunnen worden. Dan kunnen bedrijven en developers ervoor kiezen om bepaalde bedrijven te vermijden en kunnen andere bedrijven developers niet aannemen als ze op het CV dergelijke bedrijven zien staan.

Ow ja, laat ons wat collega's aan de schandpaal nagelen, dat helpt vast

Andersom zouden bedrijven (zowel IT bedijven als hun klanten) juist meer aandacht moeten hebben voor kwaliteit. CV, voorgaande producten, certifiëringen, ... kunnen allemaal helpen, maar ik pleit voor een kwaliteitslabel voor software- en IT sevice bedrijven!

Het is geen schandpaal, maar transparantie. Het is licht schijnen in de donkere wereld van de brakke IT. Je naait geen collega's erbij, maar dat soort lui naaien vooral anderen. De prutsers die het voor een prikkie onveilig doen ontnemen de serieuze partijen de opdrachten, want die kunnen dat inderdaad waarschijnlijk niet voor zo weinig doen. Daarnaast duperen ze eindeloze hoeveelheid gebruikers van hun systemen.

Als developer weet ik ook graag met wat voor partij ik zaken doe, want elk IT bedrijf heeft mooie praatjes en beloftes. Die kennen we nu wel. Allemaal innovatieve partijen die de hoogste eisen stellen aan de werknemers. Totdat je achter de schermen kijkt en je merkt dat het een tikkende tijdbom is zonder enige mechanismen en controles om een ramp te voorkomen.

En vaak hebben dat soort bedrijven allang allerlei behaalde awards, kwaliteitslabels en certificeringen. Die betaalde grappen zijn een wassen neus en een business op zich. Die zijn er dus allang en helpen geen reet.

Iemand publiekelijk oplijsten om het maken van fouten, das een schandpaal.
Als dat dan nog om bedrijven gaat, ok. Maar mensen hun carrière opblazen omdat ze meewerkten aan een project met issues? Dat lijkt me toch een paar bruggen te ver.
Ook is zo'n lijst bijna onmogelijk objectief bij te houden.
Imho zijn bedrijven zelf verantwoordelijk voor de pipo's die ze inhuren.

Vandaar dat ik het langs de andere kant zou aanpakken en kwaliteitslabels zou gebruiken voor bedrijven/producten/diensten waaraan relatief strenge voorwaarden aan verbonden zijn. Zoiets mag iets kosten (want zo'n logo is kostbaar) én levert iets op (op zijn minst een vorm van externe audit). Tesamen met een sensibiliseringscampagne en bijvoorbeeld overheden die alleen nog diensten mét label willen, moet dat toch resultaten boeken? Met eco-labels voor witgoed is dat toch 'gelukt'?

Schandpaal gaat misschien idd wat ver maar ik vind dat mensen wel verantwoordelijk mogen worden gehouden voor het afgeleverde werk. Jij bent de expert en wordt ervoor betaald goed werk af te leveren. Als jij de middelen niet krijgt om goed werk af te leveren heb je wat mij betreft de verantwoordelijkheid niet alleen dat aan te kaarten maar actief weigeren slecht werk af te leveren. Het lijkt mij zeer waarschijnlijk dat als je werkgever je vervolgens zou willen ontslaan of weigeren te betalen dan win jij mits je kan aantonen dat de werkgever iets van jou verlangde dat niet wenselijk is. Ik vind het dan eigenlijk slecht dat werknemers accepteren slecht werk te leveren en zich verschuilen achter een 'het moest van de baas'. Je wil toch trots kunnen zijn op je werk en helemaal als beetje fatsoenlijke IT'er geldt voor jou dat voor je huidige werkgever 10 anderen

[Reactie gewijzigd door warcow op 5 augustus 2017 09:39]

Iedereen is bang voor zijn eigen hachie..... Niet iedereen staat zo sterk in zijn/haar schoenen om op te komen voor je principes met de kans je baan te verliezen.

Ik vind het dan eigenlijk slecht dat werknemers accepteren slecht werk te leveren en zich verschuilen achter een 'het moest van de baas'. Je wil toch trots kunnen zijn op je werk en helemaal als beetje fatsoenlijke IT'er geldt voor jou dat voor je huidige werkgever 10 anderen

In de IT misschien wel maar in de meeste andere branches is het zo dat mensen echt wel afhankelijk zijn van hun werkgever (de wetgever houd daar ook al rekening mee). In de meeste branches geldt dat die werkgever voor jou niet alleen 10 anderen kan vinden maar dat er voor die éne functie 100 tot 500 kandidaten zijn.

Daarbij, ook al vindt je relatief makkelijk een baan, je zal ook enige tijd moeten kunnen overbruggen zonder inkomen (WW aanvragen duurt tegenwoordig al 2 maanden) en sinds de crisis heeft een heel groot deel van de Nederlandse bevolking die buffer ook niet meer.

Schandpaal is een straf om iemand belachelijk te maken, dit is de markt informeren over partijen die aantoonbaar privacygevoelige gegevens van gebruikers niet goed hebben beveiligd.

Misschien moet je soms inderdaad wat carrières opblazen om te voorkomen dat die van honderdduizenden anderen in gevaar komen. Privacy is niet iets waarmee je risico's mag nemen. Leuk als er duizenden foto's van den kamasutrabeurs of secondlove event online staan met naam en e-mailadressen erbij.

Een eco-label is heel wat anders, want dat is makkelijker meetbaar dan veiligheid. Ik heb bedrijven gezien die ISO gecertificeerd waren en daar bij een aangekondigde audit aan een checklist voor moesten voldoen. Een minuutje in de sourcecode kijken en je zag dat het brak was.

Dus ik ga bij een bedrijf werken dat de beveiliging niet op orde heeft als developer, maar nog niet op de lijst staat... Na enkele maanden aandringen de beveiliging te verbeteren verlaat ik die tent en geef ze op....
En dan kom ik niet meer aan werk omdat ik of gewerkt heb bij een fout bedrijf, of omdat ik een klokkenluider ben...
Dat gaat natuurlijk niet werken.

Niet alles wat je programmeert is privacygevoelig en het is simpelweg iets waar ze naar kunnen vragen op je sollicitatie. En inderdaad zal je inderdaad wel eens hebben dat wat programmeurs moeilijker aan het werk komen of een ander vakgebied moeten uitzoeken.

Maar dat is beter dan weer de gegevens van honderdduizenden mensen op straat. Iedereen denkt alleen aan eigen belang in plaats van het algemeen belang.

IT'ers doen vaak alsof de bedrijven en programmeurs het slachtoffer zijn van een lek in plaats van dat ze de oorzaak zijn en de gebruikers het slachtoffer zijn

Nee,
Bij de overheid en bijvoorbeeld de olie en energie industrie kom je dan niet meer binnen. Als die lijst er is. Dan zal die ongetwijfeld meegenomen worden in het integriteitsonderzoek en val je daardoor af.
En de echte vraag is als je jezelf hooguit schade doe en het niets oplevert waarvoor zou je?
En ga nou niet vertellen dat je, je toekomst moet op offeren voor een "groter" doel.

Nog zo'n leuk voorbeeld ik ben recent gedetacheerd geweest bij de belastingdienst, IV accent. Ja daar is een Zembla uitzending over geweest. Met bigdata had ik helemaal niks te maken. En doordat ik toevallig daar gedetacheerd was zou ik nu een vlekje moeten krijgen door iets waar niets mee te maken had, geen idee had van wat daar gebeurde, en al helemaal geen toegang had tot die data.
Ik denk dat ik een schade vergoeding zou claimen desnoods een proces tegen de staat zou beginnen.

Een kwaliteitslabel...krijgen we wéér een nietszeggend keurmerk. De Nederlandse ziekte noem ik het al. Ik zie elk jaar weer gestrande reizigers op het 8u Journaal die geboekt hadden bij een ANVR reisburo waar de ANVR hek genoeg niet van wist dat ze lid waren...

Nee, als ik ergens géén vertrouwen in heb is het wel certificaten en keurmerken. Bedrijven gaan dáár expliciet op sturen en dat leidt nergens toe. Auto's worden ook gebouwd om te scoren op de NCAP test. En dat wil écht niet zeggen dat ze superveilig zijn, maar dat ze perfect die test kunnen doorstaan. Een real-life botsing kan heel anders uitpakken. Dat bleek wel toen men een paar hoog scorende auto's volgens een iets andere norm ging testen (minder overlap bij frontale botsing). Ineens waren de 'veilge' auto's een death trap.

Of naming and shaming een oplossing is weet ik niet. Feit is dat men overal verantwoording moet nemen. De klant moet zich ook op een of andere manier ervan vergewissen dat wat de ontwikkelaar (in - of extern) levert kosjer is. Of we dat door een (onafhankelijk) keuringsinstituut moeten laten doen is de vraag. Ik heb geen idee hoe onafhankelijk ze zijn. Of hoe lang. Daar zijn talloze voorbeelden van uit het verleden. Kijk naar de rating agencies en de kredietcrisis. Dat waren ook zogenaamd onafhankelijke instanties waar zelfs regeringen te rade gaan.

Certificering is ook een wassen neus. Heb ik in ieder geval geen bal vertrouwen. Teveel belangen betekent eigenlijk automatisch dat het op enig moment corrupt raakt.

Hoe zou een database met dergelijke bedrijven beveiligd moeten worden?

Gewoon openbaar. Het moet voor iedereen transparant zijn met wat voor bedrijf je zaken doet.

Net zoals beveiligingslekken in software gepubliceerd worden.

Er zijn hier twee levensgrote problemen:

1) Hoe krijg je het bij bedrijven tussen de oren dat ze serieus naar beveiliging moeten kijken?

Ik denk dat je nog geeneens naar bedrijven hoeft te kijken, maar eerder naar onze vakbroeders. Het zijn de developers die moeten gaan zeggen (en implementeren) hoe het moet. Een manager van zo'n bedrijf wil alleen maar dat zo'n hokje werkt (die gaat echt niet specificeren dat je geen sql injectie mag gebruiken). Het development team is verantwoordelijk voor de technische invulling.

Een eerste stap daarin is dat IT-ers leren communiceren op managementniveau. Dus geen technische details wat zo vaak gebeurd, maar de business impact van bepaalde keuzes toelichten en verdedigen.

"Een eerste stap daarin is dat IT-ers leren communiceren op managementniveau."

Mijn mening is dat hiervoor een apart persoon voor aangewezen moet worden. Momenteel volg ik de opleiding Networking & Security Enginering, waarbij me uitgelegd werd wat dit precies in houd. De opleiding zou mij leren hoe ik een goed veilig netwerk opzet van scratch, een bestaand netwerk beveiligen en eventuele hacks traceren om uit te zoeken waar het fout ging om hier vervolgens van te leren en lekken te patchen.

Tot zo ver de theorie. De realiteit is zo dramatische verschillend, dat we alleen maar bezig zijn met zulk soort dingen, en nauwelijks aan de beloofde onderdelen toekomen. Het gene waar mijn persoonlijke interesse ligt, komt nauwelijks tot helemaal niet aan bod. Zo heb ik na 3 jaar tijd toch al geleerd hoe ik een PHP form kan posten (uiteraard zijn injecties niet aan bod gekomen).

Dat beveiliging vanaf jongs af aan aan bod moet komen, ben ik mee eens. Ik vind ook dat hier (goeie) lessen over gegeven moeten worden op school. Ik ben ook van mening dat wanneer iemand zich in dit onderwerp wilt specialiseren (zoals mijn initiële gedachte gang was toen ik begon met de opleiding), die persoon ook daadwerkelijk opgeleid moet worden tot specialist. Ik ben persoonlijk dan ook van mening dat communicatie met het management via een apart aangestelde persoon moet gaan, die geen vraagtekens heeft wanneer een security specialist hem wat verteld zoals het management vaak wel doet.

Tijdens mijn werkervaring, als ICT'er binnen bedrijven en scholen, heb ik dit meerdere keren mee gemaakt. "Je regelt het maar" krijg ik van het management te horen terwijl ik meerdere keren roep dat het anders moet. "Dit kost veel te veel geld, dat doen we niet!" als ik zeg dat zwaar verouderd hardware (wat de beveiliging standaarden van vandaag de dag niet ondersteund) vervangen moet worden. Zo kan ik nog wel even door gaan.

Maar goed. Waar moet je heen met deze problemen als niemand naar je luistert, of niemand naar je wilt luisteren? In het werkgebied krijg je op je flikker of raak je in extreme gevallen zelfs je baan kwijt als je er tegen in gaat. Op school krijg je te horen "Je betaalt 'maar' €2000,- en dat is niks als je naar het totaal plaatje kijkt. We kunnen natuurlijk niet alles doen.".

[Reactie gewijzigd door cakemasher op 4 augustus 2017 16:04]

Maar goed. Waar moet je heen met deze problemen als niemand naar je luistert, of niemand naar je wilt luisteren? In het werkgebied krijg je op je flikker of raak je in extreme gevallen zelfs je baan kwijt als je er tegen in gaat. Op school krijg je te horen "Je betaalt 'maar' €2000,- en dat is niks als je naar het totaal plaatje kijkt. We kunnen natuurlijk niet alles doen.".

Er zou eigenlijk wettelijke verplichting moeten komen om dit soort misstanden te melden bij controlerende organen en wettelijke bescherming voor de meldenden.

Maar ja; Nederland doet het op klokkeluiders-gebied al zo slecht dat dat ook nooit zal gaan werken.

Managers onwterpen geen programma's. Helaas beslissen zij wél hoeveel tijd er is voor een project. En developers proberen dan daaraan te voldoen. Ik heb nog maar weinig bedrijven meegemaakt waar er een goede, solide policy lag waar alle software aan moest voldoen. En dan een policy die ook nog eens actief enforced wordt. Ik ken wel bedrijven waar dit zeer serieus genomen wordt, maar die worden daartoe reeds gedwongen door wet-en regelgeving (bankwereld en bedrijven die iets met betalingen doen).

Maar het is weldegelijk aan de developers om aan te geven hoeveel tijd het kost om iets te doen. En met "doen" bedoel ik dan direct "goed te doen". Dat is een kwestie van een professionele standaard hooghouden. Je kan een feature niet bouwen in een tijd minder dan T, omdat je geen slecht werk levert. Marchanderen met de kwaliteit van je werk is simpelweg onprofessioneel. En ja, op dat gebied moet onze beroepsgroep zeker nog grote stappen maken. Je kan je schuld niet naar managers schuiven: je bent zelf verantwoordelijk voor wat je bouwt en wat je oplevert.

Een developer heeft helemaal geen zeg op wat er gebouwd moet worden. Jij krijgt een analyse binnen met de vereisten waar jij een schatting en opmerkingen op kunt geven. Je beslist helemaal niet wat de inhoud van het project wordt. De project manager en/of klant bekijken je schatting en opmerkingen even, bekijken de kosten en baten en kiezen wat zij wensen.

Je doet alsof een ontwikkelaar een superheld is die ontslag moet nemen omdat hij niet akkoord gaat met de beslissingen van het management...

Zelfs als je als zelfstandige werkt en niemand boven je hebt, twijfel ik of je werk gaat weigeren omdat de klant niet meer wil betalen voor betere security of testen.

Dit is natuurlijk sterk afhankelijk waar de dev werkt, en voor wie die werkt.

Tevens is de afweging helemaal niet zo makkelijk. Aan de ene kant heb je de kosten om beveiliging te ontwikkelen, aan de andere kant de kans dat de huidige beveiliging niet genoeg is, tezamen met de mogelijke kosten van een breuk. En dan ben je er nog niet, stel de maximaal haalbare beveiliging is 100%, dan is het waarschijnlijk dat van 90 naar 100% gaan veel duurder is (qua ontwikkeling) dan van 80 naar 90. Waar het meest efficiente stoppunt is zal een erg lastige berekening zijn. En voor veel bedrijven, zoals de apenheul hier kan ik me voorstellen dat een lage beveiliging het meest efficient is, ja ze hebben een breuk, maar gaan hierdoor minder mensen naar de apenheul, of minder fotos maken?

Als developer kan je er wel rekening me houden dat extra security inbouwen gewoon meer tijd kost. i.m.o. moet je daar hard in zijn want je wilt niet als developer verantwoordelijk zijn voor een eventueel makkelijk lek wat na een paar maanden na het lanceren van de applicatie gevonden wordt.
Jij moet als developer dan ook aankaarten dat beveiliging tijd nodig heeft en dus geld kost.

Ja, in theorie. Ik werk al sinds 1989 in de ICT en ik zie ICT'ers inmiddels als een soort Lemmings. Ze weten waar de afgrond is, maar lopen er vrolijk heen en stappen gewoon over de rand.

En dat geeft dus direct aan wat ik bedoel.

Ik loop ook al een behoorlijke tijd rond, en ik ben op basis van die ervaring van mening dat de beroepsgroep als geheel gewoon uiterst onprofessioneel is. En ja, dat ik inclusief ikzelf, zeker als ik terugkijk naar hoe ook in het verleden dingen heb aangepakt. Dat zou niet moeten kunnen. Er vallen nog vele inhaalslagen te maken op het gebied van het toepassen van best practices, code reviews, onderhoud, opleiding en vele andere aspecten. Zolang developers zichzelf als beroepsgroep niet serieus nemen, zullen managers dat zeker ook niet doen.

Niet om heel lullig te zijn, maar 'best practices' is toch vaak ook in the eye of the beholder, omdat veel developers het op een bepaalde manier vinden dat het zo gedaan moet worden wil nog niet zeggen dat het ook de beste manier is.

Een belangrijke stap is integriteit. Sta voor een minimum aan kwaliteit. Als je vindt dat door een opgedrongen manier van werken de kwaliteit van het eindproduct (of dat nou een dienst is of een product), weiger daar dan gewoon aan mee te werken.
Ik heb dat zelf in mijn carrière 2 keer gedaan, waarvan een keer toen ik nog redelijk junior was. Een collega had eea gebouwd voor een klant en ik moest er wat aan bijbouwen toen ik zag dat het op zijn zachtst gezegd als een kaartenhuis in elkaar zat. Uiteraard niet meteen iets aan de klant gezegd, maar in de avond die collega gebeld met de vraag wat ie gedaan had. Bleek dat het onder 'dwang' van de klant op die manier gedaan was. Hij was ook junior en had wel een beetje weerwoord, maar de 'deskundoloog' (na één cursus) van de klant hield vol en heeft mijn collega dat dus gedaan. Ik zei tegen mijn collega dat ik daar niet aan mee wilde werken, want ons bedrijf zou er later mee in de problemen kunnen komen en ik besloot na overleg het met onze directie op te nemen. Na wat tegensputteren heeft de klant uiteindelijk het boetekleed aangetrokken en toegegeven dat ie zich er niet mee had moeten bemoeien.
Het had mij niet veel geïnteresseerd als ik mijn baan erdoor kwijt zou zijn geraakt. Ik was in ieder geval integer en heb geen rommel gebouwd.

Een ander geval was een pure integriteitskwestie. Mij werd gevraagd een rapport zo te schrijven dat het bedrijf van de manager een leuke opdracht zou krijgen. Dat vertik ik, want dan moet ik een foute conclusie trekken en mijn naam en de naam van mijn werkgever eronder zetten. Dat doen wij niet. Dus ja...opdracht was snel klaar...

Beide opdrachtgevers waren overigens overheid, de een een lokale overheid en de andere semi-overheid. Ik zou dus in feite meewerken aan de verspilling van belastingcenten. Ik noemde dat ook een keer bij die klant. Vreemde blikken alom...

Is het ook niet afhankelijk van de tooling? Volgens mij moet je behoorlijk wat moeite doen om in entity framework of laravel een sql injection te bouwen.

Niet persé wat mij betreft. En de opmerking was veel breder bedoeld dan web-gerelateerde ontwikkeltrajecten. Ik ben zelf primair bezig met C++, en ook daar gaan natuurlijk dingen fout. Ik denk dat dat niet zo heel veel met de taal of het platform te maken heeft.

Yep, en dan zeg je dus hoeveel tijd het waarschijnlijk gaat kosten, en dan zegt de manager, nope, het moet in minder tijd, hoe je het doet is jouw zaak. Of dan heb je aangegeven hoeveel tijd jij denkt nodig te hebben, en dan blijkt het dat je veel te weinig tijd hebt ingeschat (zelf heb ik heel veel moeite om fatsoenlijk in te schatten hoeveel tijd ik ergens voor nodig heb, vooral omdat ik alles nog moet uitzoeken en vaak ook nog tegen problemen aan loop EN nog een hoop ander werk tegelijk moet doen). Ik blijf het nog steeds knap vinden als mensen goed kunnen inschatten wat het aan tijd gaat kosten (tja, als alles al van te voren goed is gespecificeerd en voorgekauwen dan is het een stuk makkelijker ja, maar in mijn ervaring is dat 99 van de 100 keer niet).

Hoge boetes lijkt me een goed begin ja

Volgende stap is alle bedrijven die software schrijven verplichten aan bepaalde veiligheidsnormen te voldoen. Wat ook ge-audit wordt. Net als in bijna elke ander technisch bedrijf in NL moet. Dus een bepaald niveau van testen door onafhankelijke testinstelling/bedrijf, en een hackathon/penetration test achtig ding waarbij dus gekeken wordt naar o.a. super basic dingen als sql injection.

Als je daar niet doorheen komt mag je product niet in de EU worden verkocht.

Vanaf volgens jaar kun je als bedrijf tot 10% van je concern jaaromzet beboet worden bij een datalek met een minimum van x, nu is het slechts maximaal een goede 800.000 Euro, wat ook al serieus geld is, maar niet vergelijkbaar met de miljarden omzet die de echt grote bedrijven maken.

Daar staat naast, er moet ook geld zijn, als startup in je garage beginnende heb je niet even 35.000 Euro liggen voor een goede PEN test inclusief code review, of om een boete te betalen als het fout gaat, je neemt het risico dan maar voor lief.

Wil je dit echt goed krijgen, moet beveiliging aangeleerd worden van jongs af aan, dan helpen die jongere mensen ouderen ook weer het uit te leggen en verder te ontwikkelen. Het moet onderdeel worden van onze cultuur. Vergeet niet, veel mensen zijn opgegroeid in een andere tijd en hebben moeite om alle ontwikkelingen te volgen.

Hopelijk gaat die wet iets veranderen. Maar ik weet nu al dat er bedrijven en instellingen zijn die er niet aan gaan voldoen, simpelweg omdat ze te laat begonnen zijn. Hoe kan dat nou, vraag je je af. De wet is immers al jaren geleden aangekondigd en is in principe al van kracht, alleen vervalt volgend jaar de 'we knijpen een oogje dicht' periode omdat iedereen begon te piepen. Helaas is Nederland, Polderland dan weer zo dom om daaraan gehoor te geven. Iedereen was al jaren op de hoogte dat het zo zou worden, en doordat ze al die tijd op hun handen zijn blijven zitten waren ze te laat. En dat is natuurlijk de schuld van de overheid...

Beveiliging moet inderdaad worden aangeleerd. Misschien wel een leuk nieuw vak voor op de basisschool: digital awareness (of een leuke kinderachtige Nederlands kreet) waarin je naast beveiliging ook meer leert over hoe het internet (helaas) werkt. Dan snappen de kinderen dat ze niet elke scheet die ze laten niet op snapchat moeten zetten. Omgaan met de technologie enzo. Er zijn genoeg onderwerpen. Kan iets zijn zoals het uurtje maatschappijleer dat we vroeger hadden. Les over zaken als veiligheid kun je afwisselen met het leren herkennen van nepnieuws, manipulatie, oplichting, kettingbrieven, clickbait en weet ik wat meer. Kan best nuttig zijn.

maar dat is after the fact. ik wil preventie.

als je een bank wil beginnen moet je ook super veel kapitaal hebben liggen. Om mensen zoveel mogelijk te beschermen tegen de andere potentiele DSB banken die door handige jongens worden opgezet met als enkel doel snel rijk worden.

hetzelfde mag van mij voor software bedrijven gelden. als je miljarden aan venture capital kan krijgen met een halfbakken idee, kun je ook veiligheid betalen.

tja, probleem is wel dat een hoop jongeren nog heeeeeeeeeeeeel veel kunnen leren van die ouderen, want een hoop jongeren hebben heel vaak geen idee van hoe het onderliggend werkt en hebben ook vaak moeite met het oplossen als iets niet werkt (tuurlijk, uitzonderingen zijn er altijd).

Wat dat betekend is dat development nog duurder gaat worden, en wat moet er gebeuren met software die al jaren geleden geschreven is maar nog steeds onderhouden moet worden.
Het is allemaal niet zo simpel. Denk dat er dan sowieso nog maar heel weinig verkocht mag worden.
Het is heel makkelijk om van de zijlijn dit soort opmerkingen te maken, maar fouten worden nu eenmaal gemaakt, en ook wat betreft veiligheid veranderd de visie ook nog eens regelmatig.

als er een vliegtuig neerstort, zegt men dan "fouten worden nu eenmaal gemaakt"? Nee, men identificeert de fout en zorgt dat hij veel minder vaak voor zal komen.

Denk dat er dan sowieso nog maar heel weinig verkocht mag worden.

Mooi. Eindeijk de bezem er eens door. Een voorwaarde voor veilige software is trouwens dat het Open Source is. (Nee, het is geen garantie dat 't dan veilige software is. Maar dat zei ik ook niet. Ik zei dat het een voorwaarde is.)

Voorwaarde van veilige software dat het opensource moet zijn? Never gonna happen, en zou ook te gek voor woorden zijn.

Er zijn hier twee levensgrote problemen:

1) Hoe krijg je het bij bedrijven tussen de oren dat ze serieus naar beveiliging moeten kijken?
Een ander artikel van vandaag bericht over de vrij makkelijk toegankelijke zonnepanelen, en zo'n beetje elke dag wordt duidelijk dat anno 2017 nog steeds producten worden gemaakt met non-https adminpagina's, al dan niet via een niet versleuteld (en soms niet eens te versleutelen door een instelling) wifinetwerk met simpele initiele wachtwoorden die nog eens overal hetzelfde zijn (en soms zelfs een zelfde superadminpassword bevatten!!!). Onvoorstelbaar. Alsof er nog nooit iets is gehacked. En bedrijven ondernemen pas actie als er een keer iets op TV geweest is of in de Telegraaf. Ze willen dus gewoon bewust de moeite niet nemen omdat het a)teveel tijd/geld kost en b)het voor de gebruikt 'te moeilijk' zou zijn en dus zou afschrikken. Doet me denken aan de introductie van de veiligheidsgordel. Autofabrikanten wilden dat niet (!) omdat je dan feitelijk zei dat een auto een gevaarlijk ding is waarin je dood kunt gaan. Dat is geen leuk commercieel verhaal vonden ze. Inmiddels heeft Volvo er zijn USP van gemaakt...

Op elektrische apparatuur zit CE keuring voor het op de EU markt mag komen. Waarom niet iets soortgelijks voor connected devices? Als er internetverbinding/netwerkverbinding gezocht wordt dan een certificering, uiteraard is ook dat niet heilig maar kun je wel een stuk beter afdekken en kunnen bedrijven zich uiteindelijk ook zelf indekken in de vorm van verzekeringen etc op moment dat dit soort gevallen voorkomen. Nu is de continuïteit van het bedrijf eigenlijk vrij snel in gevaar want je bent min of meer vogelvrij (ook voor producten die je hebt geleverd 10 jaar geleden toen dit soort dingen veel minder speelden).

CE is geen keuring, dat mocht je willen. Dat is alleen een eigenverklaring dat je aan bepaalde (papieren) voorwaarden voldoet.

OK, uiteindelijk zelfde resultaat: Als problemen met apparaat dat volgens fabrikant CE keuring heeft dan is fabrikant/leverancier aansprakelijk. Dat is stap 1, als je een guideline hebt waaraan sowieso voldaan moet worden, dan is dat voor de gemiddelde producent al een stuk meer dan huidige situatie.

Teruggaand naar bovenstaand argument, management van bedrijven onderschat vaak dergelijke risico's als hun IT department dat verteld. Is er een keurmerk waaraan ze moeten voldoen omdat anders hun corporate liability insurance niet uitbetaald dan wordt er al een stuk serieuzer gekeken en kun je ook vrij snel terugvallen op nalatigheid. In alle gevallen is een stukje regelgeving en richtlijn al een stuk beter dan wat er nu gebeurd: Er gaat wat mis, maatschappij schreeuwt moord en brand, overheid roept: bedrijven moeten hier 'rekening' mee houden.

Je blijft't hebben over "volgens fabrikant CE keuring" - nee, CE is simpelweg geen keuring.

En een "guideline waaraan voldaan moet worden" is een contradictie. Guidelines zijn suggesties, dat is niet iets waar je aan moet voldoen.

Kortom, we hebben een reguleringsprobleem, maar het is precies dit soort onkunde wat het veroorzaakt. Goede regulering vereist begrip van zowel techniek als recht.

En in mijn ervaring is recht en regelgeving de makkelijkste manier om management te dwingen, want naar operatie die dingen voorstelt die geld en tijd kosten wordt over het algemeen slecht geluisterd

Hoewel je gelijk hebt dat CE een eenvoudige attestering van de fabrikant is waarbij deze zelf beweerd te voldoen aan bepaalde normen dient deze fabrikant zelf wel de nodige certificeringen te behalen wanneer hij zichzelf en zijn claim dat het product voldoet ernstig neemt.

Het belangrijke hier is dat Europa ervoor gekozen heeft om de verantwoordelijkheid bij de fabrikant zelf te leggen, een keuze die te verdedigen is omdat fraudeurs die geen tijd wensen te steken het logo er toch sowieso zouden opzetten.

Jan Publiek begrijpt uitstekend het belang van goede beveiliging. Dat ze het niet lukt om hun apparatuur goed te beveiligen is omdat het de professionele ICT-ers geen ruk interesseert om die apparatuur en bijbehorend software zo te ontwikkkelen dat ook Jan Publiek het veilig kan instellen. Anders vallen ze maar van hun superieure kennistroon af...

Het enige bedrijf dat een poging doet om het voor Jan Publiek veilig probeert te houden is Apple met z'n iOS. Dat wordt hier door de echte Tweakers dan ook gelijk neergesabeld. Niet te rooten! Geen andere ROM op te zetten! Geen Filesysteem! Programma's alleen via de AppStore! Alles zwaar gesanboxed! Heel erg veilig voor Jan Publiek! Kortom, waardeloos....

Er is natuurlijk wel een oplossing. Als al die hele slimme jongens en meisjes die zich bezighouden met AI en jubelende berichten de wereld in sturen als zo'n programma weer eens een denkspelletje wint nu eens een heel slim, AI gebasseerd expertsysteem schrijven waarmee Jan Publiek moeite- en foutloos door al z'n internet programma's en instellingen fietst en alles optimaal beveiligd? Alsof mphillpp naast ze zit en aan het handje meeneemt?

Dat zoiets nog niet bestaat betekent blijkbaar dat het of te moeilijk is, of dat de professionele ICT wereld eigenlijk liever niet heeft dat ze een enorm stuk minder onmisbaar worden...

[Reactie gewijzigd door CharlesND op 4 augustus 2017 18:07]

Nou, Jan Publiek kijkt me anders nog steeds vreemd aan als ik over moeilijke/goede wachtwoorden begin. Er zullen meerdere categoriën Jan Publiek zijn, maar ik zie nog de meeste van de categorie die ik schets. Laten we het erop houden dat er mensen zijn die het belang niet zien en ook niets doen, en mensen die het belang wel zien, maar niet weten hoe het werkt. Dat heeft alsnog niets te maken van het instellen van een goed wachtwoord voor je mobiel, email en internet bankieren.

Dat is hetzelfde publiek dat geloofd dat een vingerafdruk veilig is, dat Facebook een goed communicatiekanaal is en dat Google het internet is.

En wanneer het moeilijk is om de gemiddelde man/vrouw in de straat duidelijk te maken wat een sterk wachtwoord is dan ga jij verwachten dat men vanuit de IT alles zomaar idiot proof kan maken? Nu dat we gebruikers eindelijk zo ver krijgen om niet langer password de gebruiken maar wel PasSw0rd41! gaan we hen weer vertellen dat dat niet goed is en dat ze beter een wachtzin zouden gebruiken om zo een veel langer wachtwoord te bekomen. Denk je dat die gebruiker nog kan volgen? Ga dan maar eens uitleggen dat ze voor elke dienst, elke website, elk programma een apart wachtwoord moeten aanmaken...

Restrictief voor de gebruiker is trouwens niet hetzelfde als veilig. Er is geen enkele reden waarom een open platform niet veilig kan zijn. Zeker wanneer het niveau van openheid kan bepaald worden door de gebruiker. En veilig? Zijn we de iCloud "hack" alweer vergeten? Opnieuw blijkt dat de gebruiker de zwakke schakel is, niet de techniek. Je moet de gebruiker dan ook niet beschermen maar opvoeden.

Je slaat de spijker op z'n kop, Blokker! Ik wil dus inderdaad een programma dat al die gemiddelde gebruikers WEL aan een veilige internetverbinding helpt en die 'beginnersfouten' corrigeert. Dat precies reageert op de manier die jij ook zou doen als je naast zo'n gemiddelde gebruiker zou staan die z'n internet probeert te beveiligen. En ik geloof direct dat dat een heel lastig te schrijven programma is waarvoor een berg AI technologie ingezet moet worden.

Maar dat vind ik een vele malen nuttiger inzet van AI dan het winnen van een spelletje schaak of GO, het schilderen van een oude meester of het halen van de maximale score bij Pacman. Maar ik denk dat te veel ICT-ers hun boterham verdienen met het oplossen van problemen en fouten van die gemiddelde gebruiker om er echt werk van te maken...

[Reactie gewijzigd door CharlesND op 4 augustus 2017 18:22]

Als je bedrijven zover hebt dat het verplicht is, dan komen de eisen voor goede wachtwoorden vanzelf , zo gaat jan publiek ook overstag.

Misschien omdat beveiliging gewoon helemaal niet zo simpel is als een hoop mensen denken (of doen denken), wat 'vandaag' als standaardfouten gezien worden, waren 'gisteren' nog helemaal niet bekend.
Goede beveiliging is een vak apart, en veel developers hebben het al druk genoeg met de stukken die ze klaar moeten krijgen dat goed nadenken over beveiliging er zeker bij in schiet. Ook vaak genoeg dus dat je code schrijft waarvan je nog niet eens zou kunnen indenken dat daar een beveiligingslek zou kunnen zitten.
De klant wil het ook gisteren hebben, niet vandaag, nee dat is misschien geen excuus, maar wel de realiteit. Het is ook erg genoeg DAT je uberhaupt rekening hier mee moet houden.

Kan tweakers niet een keer een voor newbies artikel schrijven hoe je als beginnende programmeur een veilige database en veilige server opzet. Ik lees altijd over sql injecties alsof iedereen dit kent. Ik niet en vast velen met mij niet. Ik programmeer ook als beginneling apps en ben al blij als ik iets kan wegschrijven met Sql in een database, Maar hoe doe ik dit veilig?

Ik zie duizenden van dat soort artikelen voor newbies..dus tweakers hoeft het wiel niet opnieuw uit te vinden.

Er zijn hier twee levensgrote problemen:
1) Hoe krijg je het bij bedrijven tussen de oren dat ze serieus naar beveiliging moeten kijken?
2)Jan Publiek snapt nog steeds het belang van een goede beveiliging niet.

Het is mij inmiddels glas- en glashelder dat zonder wettelijk ingrijpen dit niet opgelost zal worden. Bedrijven gaan voor winst en korte termijn zaken. Lees in alle reacties hoe "management" omgaat met dit soort zaken, wat ik helaas uit de praktijk maar al te goed herken. Jan Publiek wil werkende apparaten kopen en denkt minder dan 9 nanoseconde aan beveiliging.

Kortom, "vanzelf" gaat dit niet lukken en afwachten betekent het wachten op een cruciale hack waarbij er iets fundamenteels misgaat, zie ook het bericht over de zonnepanelen.

De enige manier die zal werken is wetgeving maken die dit soort dingen hard beboet, tot aan inbeslagname van bewezen onveilige apparatuur aan toe. Dit overlaten aan de industrie is als het luisteren naar een tikkende tijdbom en hopen dat het vanzelf zal stoppen en weggaan.

Volgend jaar gaat Algemene Verordening Gegevensbescherming in.

Deze geldt voor vrijwel elke bedrijf/instelling/organisatie. Tenzij je geen database/kaartenbak hebt met gegevens van personeel of klanten of donateurs....

Als Autoriteit Persoonsgegevens meer onderzoekers zou krijgen dan BREIN (of neem die van brein over) komen ze al een heel eind.....

Niet gek lang geleden had de voorgangers van Autoriteit Persoonsgegevens maar twee (2) auditors in dienst. Als je ze belde met een klacht over google werd je gewoon afgewimpeld bij ze.


Als autoriteit boetes mag uitdelen en deze zelf mag behouden en besteden geef je ze financiële prikkel en zullen ze op allerlei manieren misstanden willen vinden.... van meldgeld (aanbreng premie) t/m zelf actief zoeken.

Er zijn genoeg mensen die wel 10.000 euro willen vangen als ze anoniem hun multinational kunnen verraden..... BSA (Business Software Alliance) is er groot mee geworden.

Maar hoe het er nu uit ziet zal Algemene Verordening Gegevensbescherming een papieren tijger worden die alleen door dure uurtjes schrijvers (business consultant) commercieel zal worden geëxploiteerd. En zal overheid zich omdraaien en verder gaan slapen.

Zo moeilijk is dat niet hoor. In plaats van steeds het publiek voor te schotelen dat er e-mailadressen te grabbel liggen, vertel ze wat met e-mailadressen uit eerdere lekken uitgespookt werd. Als dat namelijk geen overtuigend verhaal is, krijg je de "het zal wel" reacties. Het publiek is een beetje waarschuwingsmoe aan het raken merk ik.

Edit: typo.

[Reactie gewijzigd door Adinfinitum78 op 5 augustus 2017 09:21]

Beveiliging is heel vaak een enorme last. Wachtwoorden gedoe enzo.

Als ze daar nu eens wat beters voor zouden uitvinden. Maar dat gaat niet gebeuren.

Ik denk dat het alleen maar erger wordt. Geen systeem is immers waterdicht.

Een ander artikel van vandaag bericht over de vrij makkelijk toegankelijke zonnepanelen, en zo'n beetje elke dag wordt duidelijk dat anno 2017 nog steeds producten worden gemaakt met non-https adminpagina's, al dan niet via een niet versleuteld (en soms niet eens te versleutelen door een instelling) wifinetwerk met simpele initiele wachtwoorden die nog eens overal hetzelfde zijn (en soms zelfs een zelfde superadminpassword bevatten!!!).

Tja, de fabrikant wilt spullen afleveren die out-of-the-box werken. Dan kun je dus geen https met certificaat gaan bijleveren want dat certificaat verloopt, mogelijk zelfs voor het product bij de eindgebruiker geïnstalleerd wordt. Sterker nog, https gebruiken zonder certificaat is bij de recente versies van major browsers inmiddels ook vrijwel onmogelijk geworden.

Wat wel kan is natuurlijk apparaten die als wifi-host optreden elk een eigen random wachtwoord geven (en dat op een sticker op het apparaat vermelden), zoals dat bij routers e.d. al een tijdje gangbaar is.

Verder zouden de installateurs de boel natuurlijk moeten configureren maar meestal hebben die lui wel verstand van op daken klimmen, de boel monteren en fysiek aansluiten maar niet van netwerktechnieken of internet-veiligheid. Je noemt als voorbeeld zonnepanelen, daar vaak wordt gebruik gemaakt van panelen van merk C en een omvormer merk D enzovoorts en de makers van die merken (C, D e.a.) hebben nooit rekening gehouden met het feit dat onderdelen interoperabel moeten zijn en dus buiten een basisinstelling waarbij er alles plaintekst gaat. gebruiken ze bij voorkeur propriëtaire protocollen waardoor de verschillende merken nooit beveiligd aan elkaar te koppelen zijn. Dat er gebruik gemaakt wordt van onderdelen van verschillende fabrikanten is dan weer omdat van fabrikant C de omvormers onbetrouwbaar zijn, van fabrikant D de panelen weer absurd duur en dat fabrikant E maar één soort onderdeel maakt.

Voor de mensen die meer willen weten over hoe SQL injection in de basis werkt: Computerphile heeft hier een heel begrijpelijk filmpje over gemaakt: https://youtu.be/ciNHn38EyRc

Een aanrader voor iedereen die niet weet hoe SQL injection werkt .

En voor iedereen die liever leest dan een filmpje kijkt:
https://www.hacksplaining.com/exercises/sql-injection

Op de site worden nog meer onderwerpen behandelt zoals Cross-Site-Scripting (XSS), directory traversal, code execution, session id's, information leaken, etc... Ik kan het iedereen aanraden (zeker developers) om ten minste basiskennis van deze kwetsbaarheden te hebben.

Een beetje developer test of laat zijn app testen: https://www.owasp.org/images/1/19/OTGv4.pdf

Verder kan je de OWASP Zed Attack Proxy, Netsparker (duur! maar goed) of zelfs Checkmarx eens proberen

Dat zou je hopen, helaas kan ik uit praktijkervaring (pentester) vertellen dat dat lang niet altijd het geval is. Veel developers zien een pentest nog te vaak als een soort aanval op hun werkwijze, terwijl security echt een vak apart is en beide beroepen elkaar goed aanvullen om een werkzame én veilige omgeving te creëren.

Een developer heeft hier helemaal niet over te zeggen. Deze keuze ligt steeds bij het management en/of de klant. Zodra je vertelt dat penetratietesten redelijk wat tijd en geld gaan kosten, krijg je meestal te horen dat het niet hoeft.

Tot nu toe hebben we nog maar voor 1 project zelf de tijd gehad om onze eigen software te mogene testen op security issues, zonder daarbij professionele hulp of software te krijgen.

Of havij

Dat kanaal is voor iedereen die een beetje serieus met computers bezig is een must..

Minus de mensen die allergisch zijn voor clickbait titels en popie jopie amerikaanse presentatie

En minus de mensen die geen filmpjes willen kijken, maar gewoon lezen hoe het werkt.

filmpjes ter ondersteuning van artikelen met nuttige animaties kan ik wel waarderen. Als het alleen iemand is die een pagina tekst voorleest, ja, dan is het alleen maar omslachtig

Er is niet veel Britser te vinden op JijBuis. Clickbait, heb ik ze ook nog niet op betrapt.

ze hebben een brits accent maar het (imo overdreven) strak in de camera kijken, hun gesprekstoon en de handbewegingen komen zeer amerikaans op me over

kijk voor clickbait even naar hun video thumbnails. https://www.youtube.com/user/Computerphile/videos
die hoofdjes, de memes, alleen de tekst is on point. ik had ipv clickbait titels clickbait thumbnails moeten zeggen

[Reactie gewijzigd door Origin64 op 4 augustus 2017 14:34]

Meeste thumbnails vatten gewoon de titel samen in een paar woorden minder...
Als je dat al te clickbaity vindt zou ik de rest van het wereldwijde web maar vermijden.

[Reactie gewijzigd door OttoNL op 4 augustus 2017 15:19]

het gaat dus om de plaatjes

Dus... de titel is goed, de text in de thumbnail is goed, maar omdat ze 1 op de 10x grappig kijken en graag 90's graphics gebruiken zijn ze clickbait?
Ik zie niet eens memes. Het enige wat mensen mogelijk aantrekt is een Pacmannetje.

sowieso staat die wat meme met dat oude vrouwtje in een van de thumbnails.

het zag er naar mijn mening gewoon uit als youtube poop. dat vind ik niet wenselijk voor een tech channel

het gaat dus om de plaatjes

Clickbait (letterlijk: "klikaas") is bij internetjournalistiek en bijvoorbeeld YouTube-amusement het gebruik van een misleidende, sensationele titel van een artikel, video, e.d., in een poging om de lezer tot een "klik" te verleiden en zo meer inkomsten uit internetreclame te genereren.
Het gaat dus niet om de plaatjes, maar om de titel.

Het gaat mij om de plaatjes. Heb je daar een beter woord voor?

Ja, smaak, en blijkbaar vallen de plaatjes bij jou niet in je smaak.
Met clickbait heeft het in ieder geval helemaal niks te maken, er is helemaal niks misleidend aan. De tumbs die ze gebruiken voldoen netjes aan de guidelines van Youtube, en zijn consistent, wat ze goed herkenbaar maakt.

Ook die mensen willen een beetje geld verdienen. Het youtube algoritme plaatst deze video's blijkbaar hoger in de rankings als je aan al deze onzin voldoet.
En dit is dus geen Clickbait.

de video overzicht pagina https://www.youtube.com/user/Computerphile/videos is chronologisch

[Reactie gewijzigd door Origin64 op 4 augustus 2017 16:54]

Ja, op die link wel.. Maar in de youtube Recommended for you pagina's niet.

Ik heb op die recommended page eerlijk gezegd nog nooit een video gezien die ik wilde aanklikken. werkt voor geen meter. toen youtube esports ging doen hadden ze op zn minst kunnen zorgen dat ik videos in de juiste volgorde krijg aangeraden, ipv compleet willekeurig door elkaar heen. (behalve dat kijk ik niet veel op yt)

[Reactie gewijzigd door Origin64 op 5 augustus 2017 11:07]

Ik snap oprecht niet hoe een developer nou weer een SQL-injectie lek kan veroorzaken. Is dit gewoon nooit uitgelegd of is het gewoon luiheid (kan het me bijna niet voorstellen). Het lijkt me dat je als back-end developer wel weet wat de grootste beveiligingissues zijn, waarvan de grootste natuurlijk SQL-injecties zijn.

Dan neem je aan dat beveiliging enige aandacht krijgt binnen dit bedrijf

Hier hoef je niet extra aandacht aan beveiliging voor te geven lijkt mij. Het moet gewoon een gewoonte zijn om nooit user data te vertrouwen en dus altijd prepared statements te gebruiken. Het is niet alsof dat veel meer tijd kost.

Prepared statements zijn geen 100% garantie dat je geen sql injectie kan toepassen. Veel mensen denken dat ten onrechte, denken dat ze veilig zijn maar gebruiken in hun prepared statements string concatenatie, en zijn vervolgens nog steeds het bokje. En hoeveel het niet veel meer werk is, het is wel degelijk meer werk...

Heb je daar een voorbeeld van? Ik ben namelijk ook in de veronderstelling dat prepared statements veilig zijn.

Waarschijnlijk omdat je ze goed gebruikt.
Dit is een voorbeeld:
https://phpdelusions.net/pdo/sql_injection_example

Maar ook simpelweg:
preparedstatement = "select image from images where img_deeplink = " + deeplink;
preparedstatement.execute();

Is iets wat je toch nog vaak tegenkomt.
Dat terwijl er toch overal bind variabelen worden aangeleerd.

Nooit bedacht om een prepared statement op zo'n manier te gebruiken.

Het zijn op zn minst een paar extra regels code die ge-copy paste moeten worden van stackoverflow

[Reactie gewijzigd door Origin64 op 4 augustus 2017 13:38]

Daar hoeft het bedrijf geen aandacht aan te geven. Een beetje ontwikkelaar overweegt geeneens om dit te gaan gebruiken. Er is echt geen CEO die tegen de ontwikkelaar gaat zeggen dat hij het zo moet implementeren dat er SQL injectie kan worden gedaan.

nee, dat zegt niemand, en dan hebben sommige ontwikkelaars er maling aan en leveren een compleet onbeveiligd stuk code af omdat ze per regel code of per deliverable betaald krijgen en niet per uur. wat zonder blikken of blozen of testen wordt uitgerold. Verklaar anders hoe dit kan gebeuren.

[Reactie gewijzigd door Origin64 op 4 augustus 2017 14:41]

Wat mij het meest verbaast is dat iemand nog zijn eigen SQL schrijft voor het oproepen van een database... Dit gaat toch veel makkelijker, sneller and beter via bestaande frameworks?

Ik schrijf zelf soms nog mijn eigen SQL, omdat dit voor kleine projectjes gewoon veel sneller is en makkelijker gaat als je maar een paar dingen hoeft bij te houden.

Ik schrijf nog dagelijks mijn eigen SQL, komt ook meer uit noodzaak omdat ik nog met 'oude' developmenttools moet werken, maar vaak genoeg ook gewoon om snel data uit een SQL database te moeten halen, zou zelf niet eens snellere manieren weten.
Maar vaak is het voor jou misschien wel sneller om het te schrijven, maar de performance is vaak verre van..
Vergeet dus ook niet dat niet iedereen zomaar de beschikking heeft over zulke frameworks, enuh, helaas zijn er ook steeds meer frameworks en ieder vind die zij gebruiken weer fijner (wordt daar zelfs een beetje kotsbeu van omdat uiteindelijk de nieuwere frameworks geen drol toevoegen aan de reeds bestaande behalve dan dat die weer net werken zoals anderen het fijner vinden).

Ik snap dan weer niet waarom SQL databases uberhaupt niet-prepared statements accepteren. En waarom frameworks erboven dan diezelfde interface ook aanbieden. Het is vrij onredelijk om 100.000 applicatie-developers de schuld te geven, fix het op DB nivo.

Het enige wat de database server binnenkrijgt is de SQL statement. Dit is dus zegmaar "SELECT user.id FROM user WHERE user.name = 'MSalters';". Een database server zou dus niet kunnen zien of een statement prepared is of niet.

Nee, dat is niet hoe serieuze databases werken. Een database krijgt PREPARE("SELECT user.id from user WHERE user.name= ?"), EXECUTE($prepared, $1="MSalters") binnen. Prepared statements zijn niet alleen veilig, het feit dat de DB ze kan preparen is ook een performance winst.

Oke dat wist ik niet, ik dacht dat de client dat omzette. Weer wat geleerd!

Enkele pogingen waren nodig om dit te fixen stond er. Ik denk dat het developers zijn die van toeten noch blazen weten.

sql injectie.. das toch bij de beesten af.

Wij hebben gewoon kutcollega's die nog steeds dit soort technologie gebruiken. Maar goed, wij perfectelingen zitten de hele dag op Tweakers. Het voordeel is dat wij daardoor ook geen fouten maken.

Als je een applicatie hebt die SQL injection toestaat dan moet je als software ontwikkelaar een naïeve beginner zijn, of gewoon incompetent.

Een naïeve ontwikkelaar die een SQL query moet doen, die gaat dat doen door stringetjes aan elkaar te plakken. Bijvoorbeeld: String query = "select * from users where username = '" + input + "'"; waarbij 'input' een tekst is die door de gebruiker van de applicatie is ingetypt. Als die gebruiker daar iets slims intypt kan hij zo de query iets heel anders laten doen dan de bedoeling was.

Dit is heel simpel te voorkomen, en zo'n soort fout maken in je applicatie betekent gewoon dat je helemaal niet over security hebt nagedacht, want dit is zo'n bekend type fout, het is zo ongeveer het eerste ding wat je leert als je een cursusje webapp security doet.

Dus nee, er is geen goed excuus voor de ontwikkelaar die dit toestaat in zijn applicatie. Zo iemand is gewoon geen goede, professionele ontwikkelaar. Heeft weinig te maken met perfectelingen op Tweakers.

[Reactie gewijzigd door jj71 op 4 augustus 2017 14:51]

OF het moet niet jouw specialiteit zijn, niet iedereen zit dagelijks met databases te werken. Vergeet ook niet dat genoeg developers te maken hebben met decennia oude code.
Het is wel heel makkelijk om te zeggen 'geen goede, professionele ontwikkelaar' terwijl iemand anders weer denkt, goh weet jij niet hoe encryptie op het laagste niveau werkt (tot alle ingewikkelde formules toe), goh dan ben jij geen goede professionele ontwikkelaar.....
Ook wat nu als basis fouten gezien worden waren vroeger helemaal niet zo voor de hand liggend.
En wat ook vaak gebeurd is dat een bepaalde developer die alleen maar desktopapps gewend is ineens een webapp in zijn maag stopt krijgt en daar dus helemaal geen expertise in heeft, maar geen tijd krijgt om zich goed te verdiepen.. Ja, moeilijk te bedenken voor je dat er nog genoeg developers zijn die nooit een webapp/site hebben hoeven te maken, maar die zijn er nog meer dan genoeg, en toch zijn dat allemaal 'goede en professionele developers'..

Het is dus niet allemaal zo simpel en zwart/wit als jij doet voorkomen.

Ook wat nu als basis fouten gezien worden waren vroeger helemaal niet zo voor de hand liggend.
En wat ook vaak gebeurd is dat een bepaalde developer die alleen maar desktopapps gewend is ineens een webapp in zijn maag stopt krijgt en daar dus helemaal geen expertise in heeft, maar geen tijd krijgt om zich goed te verdiepen.. Ja, moeilijk te bedenken voor je dat er nog genoeg developers zijn die nooit een webapp/site hebben hoeven te maken, maar die zijn er nog meer dan genoeg, en toch zijn dat allemaal 'goede en professionele developers'..

Als die developer op dat moment reageert door dan maar wat aan te kloten en aan elkaar te duct-tapen zonder rekening te houden met kwaliteits-eigenschappen als security, stabiliteit, etc. dan is dat dus geen 'goede en professionele developer'.

Een goede en professionele programmeur, c.q. code-aap, misschien. Maar een volledige software-ontwikkelaar is een engineer die met bovenstaand soort zaken ook rekening houdt, of het domein van de software nu binnen zijn/haar expertise-vlak ligt of niet.

Das leuk allemaal, maar daar moet je de tijd voor hebben/krijgen, vaak wordt er dan dus wel over nagedacht maar wordt er ook gekeken wat het kost aan tijd (en dus geld) om het 'goed' te doen of naar wat de gevolgen kunnen zijn door het na te laten. En genoeg punten waarvan je nog niet eens kunt bedenken dat het een veiligheidslek kan zijn omdat je er zelf nooit tegen aan gelopen bent.
Zeker onder druk wil nog wel vaak dingen vergeten worden. Jij zit blijkbaar misschien op een plek waar je alle rust en tijd krijgt om dingen 'goed' te doen, veel developers hebben dat niet.

Als je werkgever je onder druk zet, en je geen tijd krijgt om je code te checken en te laten checken, dan zijn er sowieso al twee zaken mis: 1: dat je daar als developer in mee gaat (geen eergevoel?); en 2: het management daar. In elk geval inzake het management is het toch alleen maar goed dat bedrijven torenhoge boetes kunnen krijgen? Maar er zullen wel weer mensen uit het bedrijfsleven zelf in de betreffende commissies zitten, waardoor de kans op hoge boetes nog steeds ontzettend klein is.

[Reactie gewijzigd door kimborntobewild op 5 augustus 2017 20:14]

Heel goed voorbed dat eergevoel. Beetje kromme analogie but bear with me: Als jij naar een doktor gaat en je zegt haal mijn arm er maar af want ik heb hem niet nodig. Dan zal hij je doorsturen naar een psycholoog. Hij is de professional en weet echt wel wat beter is voor je. Software developers zijn meestal slappe nerdjes die overal ja op zeggen. Ze zouden moeten leren dat zij de vakmensen zijn, die weten wat goed is voor een applicatie. Een werkgever zou alleen zijn probleem moeten aankaarten en vervolgens prioriteiten van features moeten maken. Het development team geeft aan wat mogelijk is binnen het budget. Maar security, architectuur en verdere kwaliteitsnormen valt niet over te onderhandelen.

Leuk, maar eergevoel brengt geen brood op de tafel, en de hele tijd moeten hoppen dan van baan naar baan is ook geen doen, en staat zeker niet goed op je cv.
En wie bepaald dan wat wel/niet veilig is, en op welk moment (ala in, vandaag zijn nieuwe exploit methodes bekend, hoe lang krijg je er voor om het op orde te maken, en vooral met oudere software)?

Dit gaat niet om geld. Dit zijn echt developers die er met de pet naar gooien. Een prepared statement maken waar je de input sanitized kost echt niet meer werk dan het aan elkaar concatten van sql en user input.

Zo simpel is het niet, want de beperking komt ook door de taal/frameworks waar je mee moet werken, denk vooral aan oudere software.
Ook heb je lang niet altijd de keuze, en komt de druk niet van je manager, maar door instanties etc.Leuk dat jij misschien wel netjes de tijd er in wilt steken, maar als instanties ineens zeggen, wij moeten dit 'morgen' hebben, dan heb je weinig keuze. Die instanties interesseren zich niet of jij dat wel of niet veilig kunt maken, want dat is voor hun helemaal niet interessant, zij moeten die data bv gewoon hebben.

Zoals ik al zeg queries sanitizen kost niet meer werk en hoort gewoon bij jou als vakman. Moet je je eens voorstellen dat je naar een autofabrikant gaat en zegt ik wil een nieuwe auto hebben. Ja meneer die is over 8 weken klaar. Nee nee ik wil hem volgende week al. Oja sorry meneer we zorgen dat hij er dan wel is, maar dan wel zonder airbag en gordels.

Je weet toch wel dat er wel degelijk een wachttijd is op het kopen van een auto. Als jij em volgende week wilt hebben dan heb je niet een vrije keuze, dus het is wel degelijk zo dat je dan alleen maar kunt kiezen uit 1tje zonder airbags (die zijn namelijk nog steeds niet wettelijk verplicht, gordels wel).

En waarom zou een software project dan wel afgeraffeld mogen worden? Het wordt echt tijd dat developers zichzelf eens volwassen en als professionals gaan gedragen. Zij weten wat gebrek aan security doet, management snapt dat niet.

tja, wat zijn professionals? voor veel mensen is dat ook gewoon doen wat er gevraagd wordt en niet meer niet minder, staat er niets over security in de specificaties dan kun je het misschien een opmerking doen, maar anders is het gewoon doen wat er gevraagd wordt, immers zijn zij degene die de specificaties opgesteld hebben.

Dat is echt een slappe houding en een zeer zeer groot probleem in de software wereld. Security is geen specificatie voor nodig, dit hoort bij je toolbox te zitten. Moet je je voorstellen dat huizen zo gebouwd worden. Ja we hebben geen tijd om deze muur te verstevigen, want mijn baas vind dat het sneller moet. Maarja over 2 jaar stort het in en gaat je bedrijf failliet vanwege slechte naam. Dit is serieus dus de houding van developers. Nee de gene die de specificaties opstelt snapt niets van security, het is de taak van een developer om dit aan te kaarten, en uit zijn comfort zone te komen. Ik zou tegen mijn baas zeggen:als jij wilt dat ik dit security lek bouw, zet ik jou naam erbij met email zodat je ook verantwoordelijk bent als het misgaat. Eens zien hoe snel ik het wel mag bouwen. En nu niet zeggen dat ik mijn baan dan kwijt raak, want dat is totaal niet realistisch. Sterker nog, meestal open je een aantal ogen.

Degene die de specificities op stelt is ook wel degelijk verantwoordelijk voor de security, want ik moet toch weten wat voor security ik moet inbouwen, of het nu 'slappe' security is, of hele strenge security.
En het is geen slappe houding, het is gewoon realistisch en professioneel zijn, want ook gewoon doen wat je gezegd wordt is professioneel hoor (dat jij dat niet vindt is een ander verhaal).
En welke toolbox? Elke job heeft zijn Eigen toolbox.
Uiteindelijk maakt het allemaal niets uit, de baas is de eindverantwoordelijke, hij/zij had maar moeten zorgen dat 'wij' goede security hadden moeten inbouwen (ofwel duidelijke eisen stellen).
Vaak genoeg dat je op je vingers getikt wordt als je juist te goed/veel wilt doen wat niet beschreven staat, want daardoor ben je uitgelopen en kan dus zijn dat die uren niet gedeclareerd kunnen worden.
Dat is de harde waarheid, naast dat je gewoonweg niet alles KUNT doen, enige wat je kunt doen is zorgen dat de basis beveiliging die het framework waarmee je werkt in iedergeval gebruikt wordt.

Je niet alles kunt doen. En sql injectie... Ik ben klaar met deze discussie. Dit slaat werkelijk alles.

Kun je mij trouwens je echte naam laten weten? Desnoods via PM Dan zorg ik er voor dat je nooit maar dan ook nooit in hetzelfde bedrijf komt te werken als ik. Ik werk namelijk liever met mensen die hun vak serieus nemen. Dit is een serieus verzoek trouwens, geen poging om grappig te zijn.

Goh grappig, ik geef aan hoe veel developers (uit mijn ervaring) denken, en jij gaat er meteen van uit dat ik zelf ook zo ben.. Typisch een doorsnee tweaker hier, niet zich fatsoenlijk kunnen verplaatsen in de denkwijze van anderen. Als jij denkt dat ik zo'n schaap ben die maar doet wat zijn baas zegt en niets meer, dan heb je het toch wel helemaal verkeerd.
Begin me ook een beetje af te vragen hoe oud jij bent en voor hoeveel bedrijven jij inmiddels gewerkt hebt en met hoeveel talen/frameworks.

Genoeg om te weten dat je niet met prutsers moet werken. Je onderhoud namelijk steeds meer, dus moet je zorgen dat onderhoud niet het enige is dat ie hoeft te doen. Ik kan me prima inleven in zulke developers, ik was er ook ooit zo een. Tot iemand me haarfijn uitlegde waarom ik niet professioneel was. Namelijk uncle Bob. On topic Een developer die Sql injectie niet nodig acht te fixen heeft in mijn ogen twee keuzes: zijn beroepskeuze heroverwegen, of zich inlezen in de gevaren.

Jammer dat er geen mogelijkheid is om een comment off-topic te modden en toch een plusje te geven

Je moet al een special kind of stupid zijn om heden ten dage SQL injection mogelijk te maken, maar dan:

Na enkele pogingen slaagde een ontwikkelaar in opdracht van Bitmove erin het sql-lek te dichten

Echt waar... Wtf..

Echt waar... Wtf..

Dat ziet volgens mij op het contact opnemen... En niet op het daadwerkelijk dichten lijkt mij?

Nee hoor, de nadruk moet liggen op EEN ontwikkelaar die in opdracht van Bitmove het lek heeft gedicht,

Het gaat dus niet over de ontwikkelaar die het lek vond.

Toch wel grappig, 'ontwikkelaar' met betrekking tot foto's ..

* stresstak heeft nog wel ID-11 en Promicrol boven ..

Laat ik dan hier de goede specifieke vraag stellen: Waarom worden die foto's in godsnaam op een site op het internet gezet? Kan dat apparaat ze niet direct naar je toe mailen of desnoods via LAN/bluetooth/usb kabel delen? Dit is echt van de zotten. Weet dit bedrijf wat het woord veiligheid betekent?

[Reactie gewijzigd door Origin64 op 4 augustus 2017 13:18]

desnoods via LAN/bluetooth/usb kabel delen

Jij denkt dat de gemiddelde non-Tweaker dit snapt?

Ik denk dat degenen die het niet snappen, het niet gaan snappen zolang ze niet duidelijk wordt gemaakt dat dit soort oplossingen knudde zijn. Er moet eerst een noodzaak zijn, voordat men moeite doet voor iets.

[Reactie gewijzigd door Origin64 op 4 augustus 2017 13:20]

Lijkt me ook niet aan te raden om mensen gewoon te maken om zomaar hun persoonlijke apparaten te verbinden met een willekeurig toestel uit een dierentuin, luchthaven of treinstation, en al zeker niet via USB.

Want? Dan gaan boeven skimming apparaatjes in die hardware inbouwen? Is nog steeds meer werk dan sql injection. Hebben we ook meteen een goede reden geen internetbankieren op mobieltjes te doen.

[Reactie gewijzigd door Origin64 op 4 augustus 2017 13:25]

Het gaat dan niet direct meer om het wel/niet veilig opslaan van die foto's + data die via SQL injection toegankelijk is. Er ontstaan hele andere problemen als iemand dat fotohokje besmet met malware die zichzelf voortplant op allerlei devices die worden aangesloten en vervolgens thuis zelfs wellicht weer aan een PC worden gehangen.

je bedoelt iets a la badusb? ja dat zou kunnen. schrap usb dan maar van het lijstje

Bijvoorbeeld, als dat apparaat mijn data drager besmet en zo een malafide USB device creëert.

Iets als Bluetooth of LAN is daarnaast potentieel net zo onveilig. Een 'aanvaller' ervoor kan er voor zorgen dat een apparaat iets heel anders uitserveert aan de gebruiker als de ontwikkelaar z'n bedoeling was, Bluetooth of LAN is slechts een transportmiddel dat geen kennis heeft van de data die eroverheen gaat.
Zodra mensen in een toeristische attractie iets moeten installeren of toestemming moeten geven om hun foto's te bekijken zal een groot deel dit denk ik zonder nadenken doen.

Daarnaast worden er constant allerlei exploits ontdekt in Bluetooth.
https://security.stackexc...-file-transfer-in-android

okay, ik weet ook wel dat geen enkele oplossing absoluut veilig is, dat kan alleen als je de foto door het apparaat laat printen en dan thuis met een fotoscanner inscant. Dit is voor velen te veel werk. Ik zocht dus naar een relatief veilge oplossing met wat gebruiksgemak. denk aub even met me mee; hoe zou dit dan wel veilig kunnen?

Zie mijn reactie op 84hannes hieronder.

In feite is het mechanisme wat ze nu gebruiken OK, alleen is de onderliggende data niet (genoeg) beschermd.
Ik zou persoonlijk zorgen alle codes random worden gegenereerd, dat de ruwe data versleuteld wordt opgeslagen en niet toegankelijk is van buitenaf d.m.v. SQL injections of XSS etc. En wellicht zelfs dat na opvragen van de data deze verwijderd wordt.

Direct naar de gebruiker mailen zou ook kunnen, maar is ietwat gevoeliger omdat de overdracht dan kan mislukken om allerlei redenen. Daarnaast zou een tegenargument kunnen zijn dat dit langere wachttijden oplevert (wellicht niet direct voor fotohokjes, maar wel voor andere apparaten) omdat men dan eerst ter plaatse de overdracht moet verifiëren, in plaats van zo snel mogelijk plaats te maken voor de volgende en thuis op z'n gemak de data op te halen.

de conclusie die ik hier dus uit kan halen is dat het beter is om maar een photo booth met een printer erin te zoeken

de conclusie die ik hier dus uit kan halen is dat het beter is om maar een photo booth met een printer erin te zoeken

Da's nog steeds geen garantie dat je foto's niet óók via internet te vinden zijn. Als gebruiker van zo'n photobooth kan je immers niet zien wat voor apparatuur er nog meer in die booth zit...

Dan trek je de cat kabel eruit

[Reactie gewijzigd door Origin64 op 6 augustus 2017 14:16]

Het leegtrekken van een usb device, smartfoon, camera of opslagmedium, is een simpel kunstje.
Ook malware/spyware op een smartfoon zetten is zo gebeurd. Dit is reeds meerder keren gedaan via een telefoonlader met een klein beetje extra hardware.

ja, negeer dan het woord usb even en probeer iets constructiefs te zeggen wat in de richting van een voor jou acceptabele oplossing gaat, ipv alleen maar een makkelijk doelwit aan te vallen

Op een website zetten een de gebruikers een unieke code geven/mailen om deze te bekijken lijkt me een mooie oplossing.

dat is wat ze nu doen en dat levert flink wat gebeun op zoals je kunt lezen in bovenstaand nieuwsbericht.

Zoals Chopper88 al zegt, met het concept is helemaal niets mis. Net als alle andere geopperde oplossingen kan het slecht uitgevoerd worden, maar in schril contrast tot veel van de genomende oplossingen kàn het ook veilig geimplementeerd worden. Veel veiliger dan USB en Bluetooth of andere opties.

Ja, als iedereen een hek om zijn eigen huis bouwt met mitrailleurs en schijnwerpers op wachttorens op de hoeken, dan kan het veiliger zijn dan de politie moeten bellen als er iemand inbreekt, als je het goed implementeert. Het is ook een enorme berg redundant werk.

Het internet, de chemische industrie, ruimtevaart, ontpoldering, filmopnames: het is een enorme berg werk en als je het verkeerd doet gaan er mensen dood. Is dat een reden om het allemaal maar niet te doen?

Het is een reden voor goede procedures en controles, ipv ervan uitgaan dat elke cowboy veilig cowboyt.

Precies!

Zo werkt het waarschijnlijk nu in praktijk ook al, in de link die je per mail krijgt zit die code waarschijnlijk verwerkt. De onderliggende data dient echter alsnog beschermd te worden tegen iets als een SQL injection.

Mechanisme is in feite prima, men moet er alleen voor zorgen dat de codes/links niet te raden zijn door met slimme algoritmes random codes te generen, deze versleuteld op te slaan en zorgen dat deze niet zomaar van buitenaf voor iedereen toegankelijk zijn.

Hebben we ook meteen een goede reden geen internetbankieren op mobieltjes te doen.

Als je even kijkt naar de huidige staat van kwaliteit van internetbankieren-apps en de staat van security en malware aanvallen op mobile OSes, dan heb je nu al een goede reden om dat niet te doen.

Jij denkt dat ik publiekelijk mijn eigen device aan een LAN/bluetooth/usb kabel hang ?

No thx lol.. dat is nog onveiliger dan de fout in dit topic.

Public = no go.


Was bedoeld voor de persoon waar pven op reageerde.

[Reactie gewijzigd door Marty007 op 4 augustus 2017 13:26]

je hangt je device nu toch ook aan het internet? en aan lans? en zeker bluetooth is toch wel geschikt hiervoor, je accepteert een bestandsoverdracht, dan geef je nog geen toestemming tot uitvoeren van code oid

[Reactie gewijzigd door Origin64 op 4 augustus 2017 13:49]

.. Via mijn provider.. niet via een random gratis acces point die ook nog eens dingen wil schrijven op mijn device.

Dat heb ik afgeleerd sinds ik tijdens een beurs in Utrecht dik 10 jaar geleden ineens een popup kreeg via een bluetooth advertentiemast .

Sindsdien heb ik al mijn signalen uitstaan tenzij en totdat ik ze gebruik.

[Reactie gewijzigd door Marty007 op 4 augustus 2017 13:51]

okay, en wat denk je dan van

1) alle openbare niet beveiligde wifi netwerken bij de mcdonalds, in de trein, etc
2) ziggo hotspots en dergelijke

en wat is dan volgens jou een goede oplossing voor dit probleem?

Wat ik denk mag duidelijk zijn in mijn vorige post.

De oplossing ?
Geen idee. Boeit me ook niet zo veel eigenlijk.
Iemand die vrijwillig alles toestaat op zn toestel is of onwetend of verdient het.

Voor die eerste groep zou de overheid 20 jaar geleden al een oplossing gehad moeten hebben.

je kreeg een 'pop up' via bluetooth? je bedoelt een connectieverzoek?

Loop eens langs Tuschinski theater in het centrum van Amsterdam.
Die kreeg het voor elkaar om reclame op mijn autoradio (met bluetooth handsfree) te krijgen.
_{Voor die mensen die zeggen dat het daar voetgangersgebied is: ik reed op De Munt.}

Daar wordt dus duidelijk gebruik gemaakt van een exploit in BlueTooth.

heb je het gemeld bij de stichting reclame code?

Nee, was er toen niet van op de hoogte en nu kom ik er niet meer bij in de buurt met mijn auto.

Ondanks dat ik volledig achter je eerste standpunt sta (Waarom moet dit in een database) snap ik eigenlijk niet waarom jij denkt dat LAN en USB een goeie oplossing zijn.

Hoe zie je dat voor je? Hangt er dan een USB of Lan kabel uit dat ding? Wat sluit ik daar op aan? Met welke connector enz enz.

Nee dan is gewoon uitprinten of mailen de enige goeie oplossing lijkt mij.

LAN kan ook W(ireless) LAN zijn. Dat fotobooth apparaat heeft een wifi netwerk, daar verbind je mee, hij stuurt de foto via een webform, waarheen je automatisch redirected wordt als je je browser opent, net als met wifi in de trein. Mijn oma zou het nog kunnen.

en btw; ik zei desnoods. ik prefereer mailen.

[Reactie gewijzigd door Origin64 op 4 augustus 2017 14:21]

Ooh zeg dat dan ( ) LAN en WLAN zijn natuurlijk compleet anders in dit scenario.

wlan is een implementatie van lan

Ja dat is mij bekend.

Naar iemand toe mailen zou eventueel kunnen, maar foto's mailen gaat niet altijd zo goed. Via LAN/bluetooth/usb kabel zou ik al helemaal niet graag doen met mn telefoon. Een link mailen vind ik zelf geen hele verkeerde oplossing, maar het is wel netjes als dit veilig gebeurt en het zou ook fijn zijn als die foto na een tijd weer wordt verwijderd.

Hoezo gaat dat niet goed? Je plakt de foto als bijlage in een email en verstuurt hem. Er kan niets aan fout gaan, het is automatisch encrypted als je 1 vinkje aanzet, iedereen kan het ontvangen, je hebt als bedrijf geen eigen hosting nodig behalve 1 mail server, etc

[Reactie gewijzigd door Origin64 op 4 augustus 2017 13:24]

het is automatisch encrypted als je 1 vinkje aanzet

?

Want iedereen heeft PGP of wat?

iedere online mail service die ik ken, onderhand zelfs hotmail/outlook.com, werkt in de interface naar de end user met imap met ssl, ook mijn werk email server heeft dat. ik hoop dat de servers dan ook berichten met encryption naar elkaar uitwisselen. anders zou het een beetje een wassen neus zijn.

[Reactie gewijzigd door Origin64 op 4 augustus 2017 13:29]

ik hoop dat de servers dan ook berichten met encryption naar elkaar uitwisselen. anders zou het een beetje een wassen neus zijn.

Hoop is inderdaad een uitstekende technische onderbouwde keuze...

Of de afhandeling van de e-mail tussen SMTP servers encrypted is hangt van instellingen aan beide kanten af en is bij lange na geen zekerheid.

Niet alle providers bieden TLS of SSL aan op hun POP3 of IMAP services ook.

Daarnaast kun je maar 7MB toevoegen aan je e-mail.

Ook al iets wat afhankelijk is van de gebruikte instellingen. Ik kan tot 500MB mailen. MIME encoding maakt bestanden gemiddeld wel zo'n 30% groter overigens. Dat mijn mail server 500MB accepteert wil niet zeggen dat de ontvanger, of eventuele relay hosts er tussenin, dat ook doen echter.

ga je me dan vertellen dat de meest gebruikte mail-oplossingen die zo'n bedrijf kan kiezen niet de optie hebben mails encrypted te verzenden? ik bedoel, er zijn toch zat open source en proprietary mail server implementaties die dat wel kunnen? ik weet redelijk zeker dat gmail etc, wat de meeste mensen nu gebruiken, dit ondersteunen. zit je bij een achtergestelde provider die nog in de jaren 90 mailt, ja, dan wordt het lastig.

[Reactie gewijzigd door Origin64 op 4 augustus 2017 13:56]

Kunnen? Ja genoeg, wil niet zeggen dat ze ook zo geconfigureerd zijn.

Daarbij kun je de mail zelf encrypten (is wat lastig, gezien de ontvanger dan de decryptie key moet hebben) of het transport kan encrypted zijn. Dat transport kun je van uit je client over het algemeen heel weinig invloed op uitoefenen. Je kan in je client uiteraard wel zeggen dat hij SMTP via SSL of TLS (starttls) moet vereisen, maar hoe die server het dan naar de volgende verstuurt heb je weinig invloed op en dat kan gerust plain/text zijn.

en er is geen flag oid wat ervoor zorgt dat encryption forced is en resulteert in delivery failure als er geen hele beveiligde end to end verbinding is?

De e-mail encryptie kan IK afdwingen voor de connectie met de exchange server. Het zelfde kan deze fotoboot voor ZIJN deel van de connectie. Alles wat er tussen zit mogen de exchange servers lekker zelf uitzoeken en heeft de zender nog de ontvanger iets over te zeggen.
Via een https website met juiste configuratie werkt gewoon goed en veilig. Als er een config fout gevonden wordt kun je wel gaan roepen dat het anders moet, maar de bestaande oplossing na de fix is idg gewoon het makkelijkste voor de gebruikers.

maar dit zal blijven gebeuren bij heel veel bedrijven op allerlei gebieden en er zijn niet genoeg white hat hackers op aarde om ze allemaal te grazen te nemen

Ja en? Waar gewerkt wordt worden fouten gemaakt.
Als de gevonden fouten dan netjes en zo snel mogelijk worden gerepareerd is er toch niet heel veel aan de hand? En ja fouten kunnen hele vervelende gevolgen hebben. Maar compleet uitsluiten is onmogelijk.

het kan wel veel beter. compleet uitsluiten is niet mogelijk. maar zelfs een minimale poging is nu niet verplicht. er is geen controle. alleen een boete nadat alles op straat ligt.

[Reactie gewijzigd door Origin64 op 4 augustus 2017 14:39]

Je hebt inderdaad S/MIME, maar dat werkt niet overal naartoe en dat zou de ontwikkelaar van die booth zelf ook goed moeten implementeren.
Daarnaast kun je maar 7MB toevoegen aan je e-mail. Ik weet niet hoe de kwaliteit is van de foto's uit die booth, maar als het er een paar zijn die in goede kwaliteit zijn geschoten heb je al een probleem. Als je meer gaat toevoegen heb je weer de kans dat sommige mensen weer die foto's niet ontvangen.

Nog over dat USB-kabeltje, ga je dan een Mini USB, Micro USB, USB-C, Lightning connector allemaal er in stoppen? En evt nog meer. Wat gebeurt er als ik die kabel er in stop? Waar komen die foto's terecht?

7MB is meer dan genoeg voor een foto uit zo'n booth. just jpeg it

Ik zette usb er meer bij als fallback optie voor het geval je niet draadloos wilt of kunt. iedereen heeft een mobiel bij zich met micro-usb aansluiting en veel daarvan kunnen met een adaptertje usb sticks etc. lezen en schrijven. dus dan doet die booth alsof hij een usb stick is (wat je mobiel doet als je hem aan je pc hangt) en delete de fotos zodra je je mobiel loskoppelt. write rechten krijg je niet.

[Reactie gewijzigd door Origin64 op 4 augustus 2017 13:41]

7MB is meer dan genoeg voor een foto uit zo'n booth.

Misschien, misschien niet. Een foto is al snel 3MB, maak je er 3 dan moet je al meerdere e-mails versturen.

iedereen heeft een mobiel bij zich met usb aansluiting en veel daarvan kunnen met een adaptertje usb sticks etc. lezen en schrijven

In 2015 had zo'n 25% een iPhone, daar kan dit zoizo al niet mee.

Daarnaast (wat andere ook al hebben aangegeven) is je telefoon aansluiten via dit soort manieren ook niet echt veilig.

Waar zie jij problemen in als die foto's veilig zijn opgeslagen op een server en vie een link worden verstuurd? Als ze die foto willen e-mailen zullen ze die ook op hun mail server moeten opslaan.
Als het goed is houdt dit bedrijf zich gewoon aan de Nederlandse wetgeving en hebben ze bij Autoriteit Persoonsgegevens welke data ze bewaren en wat ze er mee doen.

Waar zie jij problemen in als die foto's veilig zijn opgeslagen op een server en vie een link worden verstuurd? Als ze die foto willen e-mailen zullen ze die ook op hun mail server moeten opslaan.
Als het goed is houdt dit bedrijf zich gewoon aan de Nederlandse wetgeving en hebben ze bij Autoriteit Persoonsgegevens welke data ze bewaren en wat ze er mee doen.

Hier zit het probleem:

Waar zie jij problemen in als die foto's veilig zijn opgeslagen op een server

het is blijkbaar niet veilig. De verwachting dat fabrikanten het veilig maken, vind ik optimistisch

[Reactie gewijzigd door Origin64 op 4 augustus 2017 13:50]

Maar bij het niet veilig verwerken van je mail heb je het zelfde probleem niet?

Dat is tenminste een protocol waarbij andere mensen aan de beveiliging hebben gewerkt zodat je zelf minder fouten kunt maken.

Net als er frameworks zijn voor PHP ed. waar jaren aan gewerkt is om dat zo veilig mogelijk te maken en waar het heel lastig is om SQL injecties mogelijk te maken.

Ik zie net dat ze ook filmpjes maken, dat wordt nog lastiger mailen.

wetransfer

Wat bedoel je daar precies mee?

[Reactie gewijzigd door cornedor op 4 augustus 2017 17:24]

Dat dat ding videos via wetransfer beschikbaar kan maken

Op dat moment heb je dus een zelfde soort systeem, een mail met daarin een link naar een download. Daarnaast heeft WeTransfer geen API waarmee je iets kunt versturen

vandaar de

I see, niet bij stilgestaan

Je plakt de foto als bijlage in een email en verstuurt hem. Er kan niets aan fout gaan

Er zijn nog genoeg mail-providers die limieten stellen op de grote van een email. Daarnaast zijn er diverse spam- en ander filters die wel eens kuren hebben, en de diverse DKIM/DMARC/spf records waar fouten in kunnen zitten.
Nee, er gaat nooit wat mis met email

Er kan genoeg mis gaan, maar wat hier mis ging kan dan niet mis gaan.

Precies, ik laat soms mijn pasfoto's ook emailen als ik ze laat maken. Dat gaat via een Mitsubishi-machine. Wordt gewoon als bijlage verstuurd, veel handiger. Er is geen goede reden dit in een online database te houden.

Veel te ingewikkeld. QR code op een schermpje in het foto-hokje, met een https:// linkje wat nergens anders terecht komt (tenzij je't zélf op Facebook zet, natuurlijk).

maar dan ben je afhankelijk van de brakke beveiliging van dat pauper foto booth bedrijf, dat is nu het probleem

Waarmee je meteen een groep bezoekers uitsluit van het ooit kunnen ontvangen van hun foto/filmpje. Mensen zonder smartphone, zonder app voor QR code, die niet weten wat een QR code is, die hun smartphone thuis laten.

En waar laat je de bestanden dan voordat ze gemaild zijn (en ontvangen). En wat als er wat fout gaat bij het versturen van de foto's via email en de klant is ontevreden. Vang jij de klachen op? Je zult dit soort foto's toch echt ergens moeten opslaan waar de klant ze later vanaf kan halen. En daar is ook helemaal niets mis mee, zolang je de security op orde hebt.

Wat jij voorstelt is een zwaktebod en lost de beveiligingsproblemen ook helemaal niet op. Als je jouw oplossing slecht implementeert heb je nog steeds problemen. Buiten de onhandige oplossing om te gaan delen met een device dat je misschien niet bij je hebt....

Met opslaan "in the cloud" is wel wat mis, daarmee is de gebruiker de controle over zijn data kwijt. what happens on the internet....

direct mailen? nog steeds genoeg mailclients die beperkingen hebben in de grootte van bestanden die je kunt sturen. En hoe oud zijn die fotobooths eigenlijk niet al?

minder oud dan email

Och, zeker in het verleden kon je bij genoeg emailservices nog geen attachements van 1mb versturen of ontvangen, of zelfs uberhaupt geen attachements.

Ik denk dat het ondertussen de hoogste tijd wordt voor certificering voordat je softwaredeveloper mag worden. Er zijn natuurlijk genoeg ontwikkelaars die een formele opleiding hebben gehad, maar ook nog genoeg die ooit vanuit een (semi-)hobby situatie de IT zijn ingerold. Een beetje programmeren kan iedereen wel leren, maar de aspecten waardoor je een vakman/vrouw wordt is toch een stuk lastiger.

IT is zo'n beetje de enige sector waar je ongekwalificeerd en ongecertificeerd nog steeds heel ver kunt komen. En de andere sectoren waar dit wel moet doen dat niet omdat ze mensen willen pesten maar domweg omdat het onderdeel is van een kwaliteitsbeleid. Na meer dan 60 jaar IT is het misschien tijd om eens volwassen te worden als industrie. We zien dit soort dingen te vaak voorbij komen. Helaas zien we ook te vaak de reactie dat het de schuld van "het management". Maar een verpleegkundige die een fout maakt kan zich ook niet verschuilen achter de arts of het ziekenhuisbestuur.

Ik persoonlijk heb liever dat het bedrijf gewoon een megaboete krijgt en dan daar acties op onderneemt.

Dit is onmogelijk af te dwingen. Met de name in de hobby sfeer en in het MKB wordt er veel gerommeld. Dit soort "low-end" development heeft de mensen die er weinig van bakken. Een ander mogelijk probleem is de tijdsdruk omdat het niets mag kosten, waardoor dingen afgeraffeld worden.

Ook in het "hogere" bedrijfsleven zitten genoeg onbekwame mensen, helemaal als je er offshoring bijhaalt. Het is geen oplossing om tegen een onbekwaam iemand te zeggen "wordt maar 10 keer beter". Dat gaat die persoon nooit worden. Het is dweilen met de kraan open.

Een effectievere methode is een audit. Een security audit is betaalbaar en zal vele gaten blootleggen. Dat gaat een heel stuk sneller dan 5 jaar wachten tot je ontwikkelaar op niveau komt. Vervolgens los je net zo lang problemen op tot je de audit doorkomt.

Nog beter is een automated penetration test, waarbij je indien je prust code schrijft, je direct hierop gewezen wordt. Dit soort tools worden steeds beter, maar worden te weinig gebruikt.

Dit is echt een apenstreek…

"If you pay with peanuts, you can expect monkeys".

Hier een paar maand terug nog een foto in de Apenheul gemaakt en toevallig gister nog op Schiphol (ING here i come green screen, hier niet genoemd. Maar er is een reden dat ik een aantal email adressen heb en hier altijd een oude hotmail opgeef die toch al veel reclame binnenkrijgt. Waar ik nog niet aan heb gedacht is dat je vaak vanuit de email met de link naar de foto ook een deel met facebook/twitter/instagram knop hebt. Zouden wanneer je die gebruikt, ook je facebook profiel id opslaan?

Via een sql-injectie kan je dat vast zelf wel even vaststellen

Grote kans dat mijn foto met de groep ook gelekt is. Nou vind ik dat in dit geval geen ramp gezien het normale foto's zijn, maar toch.......

Ze zijn niet gelukt, er was de mogelijkheid tot lekkage. Gelukkig kwam er iemand achter, die gelukkig goede bedoelingen had.

die benadrukt dat hij de databases niet binnengehaald heeft.

Dit is iemand die weet dat je wel en niet mag doen, waarschijnlijk een ervaren white-hat

Natuurlijk weet je niet of iemand al het lek ooit gebruikt heeft, maar we gaan er gemakshalve maar even van uit dat ook daar onderzoek na gedaan is.

[Reactie gewijzigd door flipkipse op 4 augustus 2017 13:38]

De persoon die het lek gevonden heeft, heeft geen foto's binnengehaald.
Dat zegt nog niets over het punt dat evt. andere mensen hetzelfde lek gevonden kunnen hebben en al dan niet misbruikt.

(overigens is het whitehat en niet white head )

Ben je mooi in de aap gelogeerd.