'Bekende datalekken zijn slechts topje van de ijsberg'

Datalekken die in de openbaarheid zijn gekomen, zijn het topje van de ijsberg. Dat beweert Shawn Henry, die tot maart een hoge positie bij de FBI bekleedde. Volgens hem zijn technieken om aanvallers buiten te houden niet effectief.

"De realiteit is dat het gros van wat gebeurt, niet wordt gehoord door het grote publiek", zegt Shawn Henry, tot afgelopen maart executive assistant director bij de FBI en belast met cybersecurity. Het grootste deel van de datalekken blijft geheim, zei hij op de Black Hat-beveiligingsconferentie in Las Vegas, waar Tweakers.net aanwezig is.

"Ik heb onder de waterlijn kunnen kijken", aldus Henry. "Digitale aanvallen kunnen ervoor zorgen dat bedrijven alles verliezen." Hij zegt dat tijdens zijn FBI-tijd elke dag te hebben meegemaakt, soms zelfs meerdere keren per dag. Zo noemt hij het voorbeeld van een bedrijf dat in een weekend een miljard aan intellectueel eigendom verloor door een hack. "En dat incident staat niet op zichzelf."

Volgens Henry zijn digitale aanvallen het grootste gevaar voor de samenleving, los van massavernietigingswapens. Hij is bang dat bijvoorbeeld terroristen digitale aanvallen zullen gaan plegen. "Hebben ze die capaciteiten nu nog niet? Als we wachten is het te laat", aldus Henry.

Uiteindelijk zijn beveiligingsproblemen nooit helemaal uit te bannen, denkt de oud-FBI-topman, maar er moet wat hem betreft wel wat veranderen. Op dit moment zouden bedrijven nog te veel vertrouwen op technieken die aanvallers buiten moeten houden, zoals firewalls. Er zou echter ook op netwerken actief moeten worden gespoord naar verdachte signalen. "Je kunt je best doen om een vijandige omgeving voor aanvallers te creëren", stelt Henry.

Reacties (77)

[juggle]

Ik ben gek op tweakers.net maar ik moet eerlijk bekennen dat ik de discussie rond deze berichten meer dan zat begin te worden. Altijd weer wijzen met vingers naar bedrijven die security niet serieus nemen, domme developers etc etc. Elke bericht ontaardt in dezelfde nietszeggende discussie.

Mensen die in deze discussie comments plaatsen als: "ik snap niet hoe moeilijk het kan zijn een servertje te beschermen" zijn volgens mij de mensen die in eerste instantie de meeste gaten hebben in hun beveiliging.

Er wordt hier met een bepaalde arrogantie gesproken alsof elke ontwikkelaar die dit overkomt te dom is om zijn eigen billen af te vegen. Tuurlijk kan jij je beschermen tegen een willekeurige script kiddie die met zijn haxor script je online app loopt af te speuren naar gaten. Maar in de meeste gevallen gaat het om criminelen die heel wat meer in hun mars hebben.

Beveiliging is met de steeds krachtiger wordende computers steeds meer een wetenschap geworden waarin er met veel meer zaken moet worden rekening gehouden.
Ontwikkelingen op dit gebied gaan snel. Kijk alleen eens naar alle bots die het internet afspeuren naar 0-day exploits. De Plesk bug was nog geen 2 dagen oud of er werd over de hele wereld al misbruik van gemaakt.

Tuurlijk is er nalatigheid en spelen economische belangen een rol bij testen en beveiligen. Maar kijk nu eerst eens naar jezelf en de ervaring die je hebt of jij wel echt tegen een lek beschermd bent voordat je dat gaat roepen over iemand anders. En nee, het feit dat je tot nu toe nog niet gemerkt hebt dat iemand zich oneigenlijk toegang tot je servertje heeft verschaft wil niet zeggen dat je bij de beste stuurlui staat.

[Verwijderd]

ik snap niet hoe moeilijk het kan zijn een servertje te beschermen. CSF-firewall, Snort of Ossec of whatever IDS erop, AV in de achtergrond, dagelijks rechten herstellen, SELinux, constant systeemkritieke onderdelen up-to-date houden, etc. etc.

En dan zeggen dat je gebruikte database software het probleem gaf. Als je dat al niet kan, blijf dan met beide handen van servers af. Nog beter; voor hen die anno 2012 nog steeds moeite hebben met schrijven van input veilige code (denk dus aan MySQL injecties) en klaarblijkelijk te dom zijn om de eerste drie hits op Google op 'mysql injection protection' door te lezen en te implementeren, zou een server verbod van nader te bepalen lengte opgelegd moeten worden.

Dat veel mensen denken na 15 minuten 'how to install ubuntu' systeembeheerder te zijn, doet niet af van de lompheid die hier vaak mee gepaard gaan.

Hoe meer datalekken bekend worden, hoe beter! Misschien dat er eindelijk waardering zal komen voor een goede systeembeheerder.

[Keypunchie]

ik snap niet hoe moeilijk het kan zijn een servertje te beschermen. CSF-firewall, Snort of Ossec of whatever IDS erop, AV in de achtergrond, dagelijks rechten herstellen, SELinux, constant systeemkritieke onderdelen up-to-date houden, etc. etc.

Wat de FBI-man juist zegt is dat dat _niet_ voldoende is.

Naast een goeie bescherming, zowel op de perimeter, als door het up-to-date houden van systemen, moet je ook aktief monitoren op je lopende processen, of er geen gek dingen gebeuren.

Dus niet alleen maar ongeauthoriseerde toegang tegenhouden, wat je met jouw maatregelen doet, maar ook auditing plegen, om te kijken of de geauthoriseerde zaken wel allemaal in orde zijn. Anders vang je bijna nooit kwaadwillenden binnen je bedrijf, of degenen die zich ondanks al je preventieve maatregelen met privilege escalation toegang hebben verworven.

[Verwijderd]

Het idee van een krachtige firewall : (CSF kun je tot op het bot configureren)
Het idee van SELInux : (idem)
Het idee van Up-to-date Apache

Is dat een breach praktisch niet mogelijk is, en mocht het dan toch voorkomen, dan kan de binnendringer zo goed als niets.

Een vitaal item in het lijstje vergeten; Backups, can't do without them!

Dus niet alleen maar ongeauthoriseerde toegang tegenhouden, wat je met jouw maatregelen doet, maar ook auditing plegen, om te kijken of de geauthoriseerde zaken wel allemaal in orde zijn. Anders vang je bijna nooit kwaadwillenden binnen je bedrijf, of degenen die zich ondanks al je preventieve maatregelen met privilege escalation toegang hebben verworven.

Zaken zoals databasen zouden in principe maar door hooguit 5 man per bedrijf toegankelijk moeten zijn; lees de actueel draaiende versie. Natuurlijk is niemand immuun tegen een bedreiging van binnen uit. Social engineering is denk ik toch nog steeds de grootse bedreiging voor servers alles.

Nogmaals: bij / ben je toch wel fucked, daar kan SELinux/ lfd of wat dan ook echt niet meer tegen op (gegeven dat het om een ervaren binnendringer gaat). Een goede systeembeheerder zou echter zoveel dammen tot root moeten kunnen inbouwen dat het alleen theoretisch nog mogelijk is binnen te komen. Helaas houdt dat inderdaad vaak in dat iemand live de logs in de gaten houdt en direct actie kan ondernemen, hetgeen veel bedrijven niet nodig achten of simpelweg niet kunnen opbrengen.

[Reactie gewijzigd door Verwijderd op 29 juli 2024 19:38]

[zvbhvb]

Hoe meer lagen security des te beter.Liever een met Grsecurity gepatchte kernel in combinatie met SELinux of AppArmor (kan best).Dan worden bijvoorbeeld /etc/fstab en chroot restricties nog beter enforced.Ik spendeer liever wat tijd om zelf met iptables een firewall in elkaar te knutselen.Veel andere eentonige zaken kunnen wel makkelijk geautomatiseerd worden door een of ander scrippie te schrijven.

Maar ja de veiligheid is altijd omgekeerd evenredig aan de gebruiksvriendelijkheid.Compromissen ontkom je niet aan.Ook niet aan schlecht geprogrammeerde rotzooi die je geheugen restricties niet volgen.

[silentsnake]

hetgeen veel bedrijven niet nodig achten of simpelweg niet kunnen opbrengen.

Dit. Je zegt het allemaal wel zo leuk met bijvoorbeeld SElinux, maar als je eigen software compatible moet maken met SElinux ben je echt niet in een uurtje klaar hoor. Of een dag. Je moet elke mogelijke functie in je applicatie gaan testen en daar de beste contexten voor bedenken (als je de permissies weer te wijd open zet schiet je het doel van SElinux voorbij). Als je vervolgens in je agile development straat vaak nieuwe features toevoegd en vaak released dan moet je daar dus ook weer SElinux contexten voor bedenken en weer testen testen testen.

Bovendien dingen als Snort is ook allemaal schattig, maar dan moet je wel de tijd hebben om actief de gegevens van Snort te analyzeren en je IDS systeem er verder op te configureren. Tuurlijk heb je wel bedrijven die IDS logs voor je analyseren maar dat kost weer geld (wat je dus weer moet uit gaan leggen aan je baas).

Hoewel ik het met je eens ben dat dit soort dingen gewenst zijn is het praktisch gezien vaak geen haalbare kaart in een organisatie. Er gaat zo veel tijd en resources inzitten dat er vaak gezegd wordt dat het niet nodig wordt geacht door management. Probleem daarbij is dat dit soort security dingen alleen maar geld kosten, niks opleveren en alleen een in hun ogen een soort verzekering is waar geen garanties opzitten.

[SirBlade]

In theorie is het inderdaad heel erg simpel. In de praktijk wordthet systeem/netwerk beheerders vaak praktisch onmogelijk gemaakt.

Firewall, leuk maar voor zaken als web en mail servers moeten we toch een gat in de firewall maken.

Updates, lijtk simpel, in de praktijk een ramp.Het kost een beheerder een paar uur om de nieuwe patches te beoordelen en te installeren op een test machine. Vervolgens wordt de informatie over de patches beschikbaar gesteld aan de applicatiebeheerders en het eerstkomende servicewindow worden ze uitgerold op de ontwikkel/test machines (normaal gesproken is dat op een vrijdagavond). De week daarna worden de updates getest op de ontwikkel/test machines en als er geen problemen optreden worden ze de 2de vrijdagavond na release van de patch uitgerold op de productiesystemen.Als er problemen zijn met een update wordt het helemaal een ramp, tenzij de systeembeheerder kan aantonen dat er actief misbruik gebruik wordt gemaakt van een lek acht het management een niet-correct werkende applicatie belangrijker dan een niet-correct werkend OS. En dan hebben we het maar niet over die bagger applicaties die perse versie x.y.z van een component vereisen. En vaak zijn dit applicaties die onder de radar van de beheerders worden aangeschaft, bv omdat gebouwbeheer een nieuw airco systeem heeft aangeschaft waar een speciale beheer applicatie voor is.

Slechte ontwikkelaars toegang tot de servers ontzeggen? Dream on, security leeft niet bij het management, het product van de slechte ontwikkelaar wel. Zit hem te veel dwars en je krijgt de opdracht hem root/administrator te maken zodat hij zijn werk kan doen.

Auditing: Daar krijg je geen tijd voor.

Secuity wordt niet belangrijk gevonden totdat het te laat is.Papierwerk en processen worden vele malen belangrijker geacht.

[cire]

Een andere uitdaging aan de security kant is dat een hacker maar 1 gat hoeft te vinden. Terwijl aan de beheer kant een complete keten aan systemen veilig moet zijn. Dat is niet makkelijk aan te tonen of te organiseren.

Bij grote organisatie kan het gaan om tientallen systemen waarbij honderen mensen bij betrokken zijn.

[Squ1zZy]

Neem als voorbeeld de SQL Injectie. Elke week hoor je wel dat er dump is gemaakt van een database. Na Sony had ik toch wel verwacht dat dit NIET mogelijk zou zijn op welke site dan ook. SQL Injectie stamt af van begin 2002. Tien jaar later en nog worden er dumps gemaakt. Beheerders worden niet wakker lijkt het. Evenals het management die de beheerders zouden moeten verzoeken om het te controleren.

Tegen 0-day exploits doe je weinig. Als je maar up-to-date bent dan moet je maar "hopen" dat alles goed gaat, maar toch lees ik dat er bedrijven zijn (KPN b.v.) die hun servers/appliances/hardware niet up-to-date hebben.

Sony gaf aan een miljard te hebben verloren aan de hack alleen. Ook weer dit nieuws. Ik geef hem gelijk, maar wat moeten ze doen? Wie moet het doen? Waar moet men beginnen?

[J.J.J. Bokma]

SQL injectie stamt helemaal niet af van begin 2002, hoe kom je daar bij?

SQL injectie is gewoon het gevolg van laag geschoolde of niet geschoolde hobby knutselaars die geen kaas hebben gegeten van programmeren. In plaats van goede libraries te gebruiken plakt men gewoon strings aan elkaar om een SQL query te bouwen. Zelfs daar is niks mis mee, mits men de nodige controles doet. Maar ook dat gebeurd dus niet.

En dit soort problemen blijven gewoon voorkomen. Er zijn altijd "programmeurs" die het beter "weten", die menen dat hun eigen, nauwelijks getestte code beter is dan een bibliotheek die al jaren gebruikt wordt.

Jij meent dat SQL injects pas 10 jaar bestaan. Welnee, veel en veel langer. En het onderliggende probleem: het ongecontroleerd gebruiken van data van buitenaf om dynamisch opdrachten op te bouwen en uit te laten voeren is waarschijnlijk net zo oud als het vak programmeren.

En libraries waarmee dit simpel voorkomen kan worden, o.a. JDBC voor Java, DBI voor Perl, bestaan ook al veel langer dan 2002.

[BeosBeing]

En dit soort problemen blijven gewoon voorkomen. Er zijn altijd "programmeurs" die het beter "weten", die menen dat hun eigen, nauwelijks getestte code beter is dan een bibliotheek die al jaren gebruikt wordt.

Of ze weten niet hoe ze bibliotheken moeten gebruiken, of ze weten niet eens van het bestaan af (zouden niet eens weten waar te zoeken) en proberen dus alles zelf uit te vinden. Zo werkt het vaak met beginners, zeker als ze een opdracht krijgen en geen of onvoldoende toegang hebben tot documentatie.

[PolarBear]

SQL Injectie stamt af van begin 2002.

Zolang er applicaties zijn die doormiddel van concatten van een string SQL queries opbouwen bestaat SQL injectie. Dat is echt wel eerder dan 2002. En de oplossing, prepared statements, stored procedures etc bestaan eigenlijk net zolang.

[Squ1zZy]

Als het 10 jaar bestaat dan kan je mij niet vertellen dat ze er al iet op hebben gevonden. Tools die code checkt b.v.?
Optie in SQL om maar 1 statement mee te geven als er geen meerdere nodig zijn?

Dus jij zegt dat SQL Injectie altijd zal voortbestaan? Lijkt me sterk. Het wordt gewoon niet opgepakt...

[Niemand_Anders]

SQL Injectie bestaat al sinds de dag dat er interfaces zijn waarvan de invoer wordt gebruikt om queries naar de database te sturen.

Echter vandaag de dag verstaan we onder SQL injection het aanpassen van een url of form post als SQL/XSS injection. Toen begin jaren 90 internet wereldwijd beschikbaar (buiten de academische bubbel) en de meeste dynamische websites werden geschreven in perl CGI scripts waren toen al de SQL en HTML injecties zeer populair. Gastenboeken waar je een H1 tag in je naam kon plaatsen, cookies waarbij je zo het userid kon veranderen en kon bestellen ook naam van iemand anders.

De oplossing tegen SQL en XSS injecties is niet het gebruik van prepared statements of stored procedures, maar gewoon een erg simpel ALLE VREEMDE INVOER CONTOLEREN. Prepared statements and stored procedures zijn alleen populair omdat het eenvoudige en luie manier is om vrijwel alle sql injections te voorkomen. Echter ben je dan wel 100% afhankelijk van het feit dat er geen bug in de argument parser zit. Ook voorkomt het geen onjuiste invoer. In een naam zit gewoon geen cijfer en al helemaal geen procent tekens. Het voorkomt ook geen HTML input.

Je weet wat je verwacht, dus moet je ook controleren of je dat ontvangt. Maar helaas zijn de meeste programmeurs te lui, incompetent, onverschillig of onwetend om dat te doen.

Net zoals je een netwerk niet kunt beveiligen met alleen een firewall, kun je ook input injections niet voorkomen met prepared statements.

Maar het probleem zit niet alleen bij de programmeurs. Het zit veel dieper en begint al bij de opleiding. Ooit gehoord dat iemand zijn scriptie, propedeuse of afstudeerscriptie is afgewezen of de persoon de vreemde invoer niet controleerde? Driemaal raden wat een buffer overflow veroorzaakt? Juist een tekenreeks welke langer is dan verwacht? Dus geen controle bij invoer. HTML injectie? geen controle bij invoer. SQL Injectie? Geen controle van invoer..

Meer dan 99,9% van alle website hacks zijn te voorkomen door gewoon puur de invoer te controleren. De oplossing is simpel en kost als je het consequent doet ook niet veel tijd..

[deadinspace]

De oplossing tegen SQL en XSS injecties is niet het gebruik van prepared statements of stored procedures, maar gewoon een erg simpel ALLE VREEMDE INVOER CONTOLEREN.

Dat is echt zo pertinent onjuist dat het niet grappig is

Het probleem is er niet een van ongecontroleerde invoer, het probleem is er een van data die over taaldomeinen heengaat. Het begint als POST data (dus bv UTF-8 tekst), en wordt bijvoorbeeld ge-embed in een SQL query en daarna in een HTML pagina, en op beide punten kan die data problemen opleveren door (al dan niet expres) als deel van die taal geinterpreteerd te worden.

Als je je 'input wil controleren', dan moet je bij invoer dus voor alle mogelijke taaldomeinen waar de data zou kunnen belanden (in bovenstaand voorbeeld dus SQL en HTML) nagaan of de input problemen op kan leveren. Als je daar nog een taaldomein aan toevoegt (bijvoorbeeld door later de data ook in Javascript of CSS te embedden), dan moet je bij de invoer dus ook nog controle daarvoor toevoegen. En je databases nalopen met die controle voor data die eerder is ingevoerd. Dat soort praktijken schalen niet en zijn foutgevoelig.

Invoer controleren is sowieso foutgevoelig, en de meningen over wat wel en niet kan verschillen. Denk bijvoorbeeld aan verschillende SQL servers die verschillende opties voor string literals of commentaar ondersteunen. Als je dan naar een andere SQL server overstapt zit je dan met je subtiel anders gecontroleerde data.

Nee, de juist aanpak is om alle invoer als onvertrouwd aan te merken, en bij gebruik van de data de data zo veilig mogelijk te embedden. Dat kan bij SQL queries bijvoorbeeld door parametrized queries te gebruiken; de invoer wordt dan simpelweg nooit als SQL geparsed en kan dus daar nooit een probleem opleveren.

Embedden in HTML kan veilig door de juiste karakters - zoals natuurlijk < - te escapen. (escapen is voor SQL natuurlijk ook mogelijk maar lastiger en dus gevaarlijker, en bovendien overbodig vanwege parametrized queries).

Prepared statements and stored procedures zijn alleen populair omdat het eenvoudige en luie manier is om vrijwel alle sql injections te voorkomen.

Ik ga er van uit dat je parametrized queries bedoelt, want dat is natuurlijk waar het om draait bij SQL injection.

En nee. Parametrized queries zijn de manier om SQL-injectie 100% onmogelijk te maken. Door parametrized queries te gebruiken wordt je invoer nooit als SQL beschouwd (maar als precies dat: invoer), en vermijd je dus alle risico's die daarmee gepaard gaan.

Echter ben je dan wel 100% afhankelijk van het feit dat er geen bug in de argument parser zit.

Dat is wel het slechtste argument dat ik ooit gehoord heb. Je bent ook 100% afhankelijk van het feit dat er geen bug in alle andere software die je gebruikt zit. Je bent afhankelijk van bugs in MySQL, Apache, Joomla en PHP bijvoorbeeld. Nogal wiedes.

Ook voorkomt het geen onjuiste invoer. In een naam zit gewoon geen cijfer en al helemaal geen procent tekens.

Dat is waar, maar dat is een ander probleem. Overigens zijn cijfers en procenttekens niet zo'n groot probleem voor SQL queries, maar een enkel aanhalingsteken des te meer. En laat dat nou toevallig wel een geldig teken voor in een naam zijn (denk aan namen als O'Reilly).

Het voorkomt ook geen HTML input.

Nogal wiedes, parametrized SQL queries beschermt tegen problemen in het SQL taaldomein. Voor elk taaldomein waar je input belandt is een eigen oplossing.

Driemaal raden wat een buffer overflow veroorzaakt? Juist een tekenreeks welke langer is dan verwacht? Dus geen controle bij invoer.

Nee, onveilig embedden. Het probleem is "kopieer X karakters van een string met lengte X naar buffer met grootte Y". Maak daarvan "kopieer min(X,Y) karakters van een string met lengte X naar buffer met grootte Y", en ineens is er geen buffer overflow meer. Of beter nog, misschien kan het wel met een variabele-grootte buffer. Zo komen buffer overflows vrijwel nooit voor in talen die geen strings van vaste lengte hebben (zoals Python, Perl, of PHP).

Om het eens over een andere boeg te gooien: wat als in jouw C programma invoer langs twee buffers komt, één van 16384 bytes, en één van 4096 bytes. Invoer gebeurt op 2 verschillende plaatsen. Overal controleer je netjes of de invoer korter is dan 4096 bytes. Nu verklein je één van die twee buffers, of de data moet voortaan ook langs een nieuwe, kleinere, buffer van 1024 bytes. Dan moet je er dus aan denken om de invoerchecks aan te passen op beide invoerlocaties (als je er al uberhaupt aan denkt om de invoerchecks aan te passen). De lengte van de buffer moet op twee hele andere plaatsen bekend zijn, namelijk bij de buffer zelf, en bij de invoercheck.

Maar als je nou bij elk van de drie buffers strncpy() met de juiste lengte gebruikt om zo buffer overflows te voorkomen? Dan hoef je bij het toevoegen van een nieuwe buffer niet na te denken of de maximale lengte daardoor korter wordt en of je je invoerchecks moet aanpassen en waar die ook alweer stonden. Je houdt de maatregel precies daar waar hij gebruikt wordt.

HTML injectie? geen controle bij invoer.

Nee, onveilig embedden. Escape de HTML bij het embedden, en injection verdwijnt.

SQL Injectie? Geen controle van invoer..

Nee, onveilig embedden. Gebruik parametrized queries, en de invoer wordt nooit als SQL beschouwd.

[onox]

De oplossing tegen SQL en XSS injecties is niet het gebruik van prepared statements of stored procedures, maar gewoon een erg simpel ALLE VREEMDE INVOER CONTOLEREN. Prepared statements and stored procedures zijn alleen populair omdat het eenvoudige en luie manier is om vrijwel alle sql injections te voorkomen. Echter ben je dan wel 100% afhankelijk van het feit dat er geen bug in de argument parser zit. Ook voorkomt het geen onjuiste invoer. In een naam zit gewoon geen cijfer en al helemaal geen procent tekens. Het voorkomt ook geen HTML input.

Je hebt gelijk dat vreemde invoer gecontroleerd moet worden. Maar in de code die je invoer controleert kan natuurlijk ook een bug zitten Beter dus dat je zowel de invoer controleert en dat je prepared statements gebruikt.

[Cronax]

Daarom moet je je code dus testen als ontwikkelaar, en een security tester vervolgens het systeem laten testen. Helaas worden dit soort dingen vaak als 'overbodige kosten' gezien terwijl het op de lange termijn in bijna alle gevallen geld oplevert...

[Ergomane]

Daarnaast kan invoer simpelweg valide zijn en toch leiden tot injection (oa SQLi). Als het aan Niemand_Anders lag zouden namen met single quotes ook verboden worden.

[J.J.J. Bokma]

"De oplossing tegen SQL en XSS injecties is niet het gebruik van prepared statements of stored procedures, maar gewoon een erg simpel ALLE VREEMDE INVOER CONTOLEREN. "

Jammer... mooi verhaal, maar gemiste kans, en foutjes (klok horen luiden en zo).

Gaan we.

Prepared statements helpen *niet* tegen SQL injecties, je kan prima een query aan de hand van gebruikersingave samenplakken, en die "preparen". Nee, wat helpt is het gebruik van gebonden parameters (bind parameters), dus iets als:

'insert into table values(?, ?, ?)'

Ik neem even aan dat je die twee door elkaar haalt, wat erg jammer is als je zo van de toren aan het blazen bent.

Kan het hier mis gaan? Tuurlijk, er kan een fout zitten in de library die dit afhandelt. Maar ik vertrouw die library meer dan mijn eigen "vreemde invoer controle" (en de jouwe), ook omdat dat eerste door vele andere programmeurs dagelijks gebruikt /en/ getest wordt.

Kortom, gebruik gebonden parameters en ga die zeker niet vervangen door handgeklopte "vreemde invoer controle" zoals NA hierboven lijkt te suggereren (hij noemt het onjuist "prepared statements", maar ik neem aan dat hij dat niet bedoelt, maar gebonden parameters). En om het helemaal goed te doen, doe je natuurlijk beiden waar nodig, en altijd die gebonden parameters en dus zal ik zeker nooit "controle" aanraden in plaats van gebonden parameters.

Enne, ja het probleem zit 'm bij de programmeurs. Een opleiding is slechts een driewieler. Daarna ben je hopelijk slim genoeg om zelf te leren fietsen. Verder, ja, bij mijn opleiding werd daar zeker naar gekeken (buffer overflow).

[PolarBear]

Ik bedoelde inderdaad geparameteriseerde queries (in C# in iedergeval. (ben met verschillende talen bezig, dus ik haal af en toe wat termen door de war). Daarmee heb je al 100% SQL injectie uitgesloten. User input controleren is leuk, maar dient een ander doel.

[onox]

Kan je niet lezen? PolarBear zegt dat de oplossing, prepared statements en stored procedures, al bijna net zo lang bestaat als de eerste SQL injectie.

Zie https://www.owasp.org/ind...Injection_Vulnerabilities

Het is gewoon luiheid. Managers en developers moeten gewoon harder op hun vingers getikt worden.

[Reactie gewijzigd door onox op 29 juli 2024 19:38]

[Precision]

Tuurlijk zijn er tools beschikbaar die scannen op SQL injecties, het gros van de lekken wordt trouwens zo gevonden, via geautomatiseerde tools. Maar als ze iemand moeten betalen om iets op te lossen dan kan die persoon in tussentijd niets nieuws maken die wel geld opbrengt.

[J.J.J. Bokma]

Zelfs als je maar 1 statement kan uitvoeren kan je nog steeds dingen doen als:

$query = "DELETE FROM post WHERE post.id=" . $id;

vul nu maar eens voor $id dit in:

1 OR 1

dag berichtjes....

Al helemaal eng is het als men de tabelnaam ook van buitenaf laat komen, of nog erger de hele query in de URL... Zoek maar eens op Google met inurl: en wat leuke trefwoorden als je wilt huilen...

edit: aanvulling: hopelijk is het duidelijk dat *prepared statements* hier niet gaan helpen, want als je query nu vervolgens "prepared" en dan uitvoert heb je nog steeds hetzelfde probleem. Wat je hier wilt is *bind parameters* dus iets als:

$query = "DELETE FROM post WHERE post.id=?" # <--- placeholder
$sth = $db->prepare($query);
$sth->execute($id); # <----- dit dus

En niet:

$query = "DELETE FROM post WHERE post.id=" . $id; # <--- FOUT
$sth = $db->prepare($query);
$sth->execute(); # <--- ouch, dag alle posts.

[Reactie gewijzigd door J.J.J. Bokma op 29 juli 2024 19:38]

[Olaf van der Spek]

En de oplossing, prepared statements, stored procedures etc bestaan eigenlijk net zolang.

Het is een alternatieve API en blijkbaar geen (voldoende) oplossing. Het probleem bestaat namelijk nog steeds.

[PolarBear]

Ik bedoelde parameterized query (.Net), foutje van mijn kant. Dat is geen alternatieve API, dat is de manier om via code een database aan te spreken. SQL injectie is dan onmogelijk, of kan je mij aantonen dat het wel kan?

[Olaf van der Spek]

Beheerders worden niet wakker lijkt het.

Heeft weinig met beheerders te maken, maar alles met language / platform developers. Zelfs hier op Tweakers / GoT wijst het vingertje gelijk naar de beheerders en is er weinig interesse om het probleem fundamenteel aan te pakken.

[Reactie gewijzigd door Olaf van der Spek op 29 juli 2024 19:38]

[Squ1zZy]

Ik ben als beheerder verantwoordelijk voor het up-to-date zijn van servers/hardware right? Als er een lek gevonden wordt in de edge transport servers en er komt een update dan ben ik als systeembeheerder verantwoordelijk om de server te updaten?

[Precision]

Ik denk dat Olaf reageert op Squ1zZy zijn post over SQL injecties. Dat is iets dat de developers op orde moeten hebben en zolang zij geen update ontwikkeld hebben kan de systeembeheer het niet installeren. Dus in eerste instantie is het niet de verantwoordelijkheid van de beheerder, maar aan de ontwikkelaars om het op te lossen. Erna is het aan de beheerders om het toe te passen.

[Squ1zZy]

Aah ok. Daar heb je een punt
Ik ga er wel vanuit dat wanneer er in b.v. WordPress een lek word gevonden deze binnen enkel dagen/uren word gedicht? Een bestaand/bekend CMS systeem draaien is misschien dan altijd handig.

[Cronax]

Volgens mij klopt dit niet helemaal, zeker in het geval van SQL injecties is het wel degelijk correct om naar de beheerders te wijzen met de beschuldigende vinger, er bestaat immers een oplossing voor het probleem maar ze hebben die niet uitgevoerd.

Zelfs als hun management besloten heeft om het lek niet te dichten valt de schuld nog steeds op de beheerders, zij hebben immers onder andere als taak om hun management de juiste informatie te geven om goede beslissingen te nemen, als management de verkeerde beslissing neemt dan is de kans groot dat je niet de juiste informatie gegeven hebt.

[RvdDungen]

Dit verbaast mij dan weer helemaal niets. Wat dat betreft wordt er veel te weinig aandacht besteed aan cybercrime. Niet in de media, genoeg aandacht daar, maar meer bij de preventie er van.

Bedrijven zouden eens een paar seminars moeten bijwonen van white head hackers of beveiligingsexperts. Binnen een week hebben ze dan hun beveiliging op orde .

[Spartacus1988]

Dat is ook niet helemaal waar.
Bedrijven doen altijd een risk assesment in hun hoogste bestuurlijke laag. En daar zit juist het probleem, ze hebben niet genoeg inzicht in dit soort problemen. IT budget wordt van bovenaf bepaalt, de implementatielaag zal gerust standaard IT beveiligingstechnieken implementeren, maar die hebben weer niet het overzicht van wat er allemaal in het bedrijf gebeurt qua processen, alleen dat ze het van buitenaf dicht moeten timmeren, en daar gaat het juist fout zoals dit artikel verteld. Te veel vertrouwen op firewalls e.d. Vooral op bestuurlijk niveau moet er meer aandacht besteed aan worden en inzicht opgedaan in wat nu belangrijk is om te beschermen en hoe het beste dat te realiseren is. Een seminaar bezoeken zal dus niet voor iedereen werken.

[Yezpahr]

Yep, Netwerkbeheerder zou eigenlijk gewoon net zo'n hoge "rang" moeten zijn als een CEO/directeur. Met net zoveel belangen binnen het bedrijf, aangezien het nu gewoon het meest bedreigde en risicovolle structuur binnen een bedrijf is in deze eeuw.

[wauwwie]

Dus jij zegt dat als je je netwerk beveiliging op orde hebt je veilig bent? Misbruik ligt in de protocols niet in de waar je wel en niet heen mag op het netwerk. Immers de mensen moeten wel kunnen werlen, dus ze mogen al bij alle belangrijke data.

Beveiliging is niet alleen op netwerk, maar op alle niveau's en vereist een mentaliteits verandering.

Hoevaak ik al niet zomaar binnen gelaten ben bij bedrijven, en dan nog een handig pasje krijgen waar je bijna overal mee naar binnen kan. Even snel een usb stickje in wat laptops steken, of nog simpeler wat hier en daar rondstrooien en de trojans vliegen door het bedrijf heen.

[witchdoc]

Dat heeft al een 'naam' hoor: CIO

[Yezpahr]

Die functie bestaat inderdaad al, maar er mag nog wel het een en ander vernieuwd worden. Tegenwoordig krijg ik het idee dat er met vriendjespolitiek iemand de CIO functie krijgt en niemand bezig is het bedrijf te verbeteren tegen de huidige en recente dreigingen.

Internet is een gevaarlijke manier van adverteren. Tuurlijk, je krijgt veel klanten en clicks en die klanten lopen niet eens bij je weg als je hun gegevens lekt of verliest, dus waar is het dan gevaarlijk zou iemand zich kunnen afvragen.

Het word pas gevaarlijk als we de bedrijven een functie toevertrouwen die ze niet kunnen hooghouden. Bijvoorbeeld het bewaren van je vingerafdrukken, dna-gegevens, geïmplanteerde chip gegevens en eventuele genetische afwijkingen van iemand.

Want hoe wil je als staat zijnde die gegevens beschermen als je tegelijk al hebt aangetoond dat internet inherent onveilig is?

[Verwijderd]

Yezpahr, ik ben het geheel met je eens betreft je 2e en 3e punt,

Punt 1 gedeeltelijk, in mijn mening maakt het namelijk niet uit welke titel je een persoon geeft. Een netwerkbeheerder gelijkstellen aan CEO lijkt me totaal overbodig met een goed functionerende of beter nog goed geïnformeerde CEO.
Een CEO is verantwoordelijk voor het bedrijf en daar vast IT gewoon ook onder net als alle andere aspecten., vanuit dat uitgangspunt niet meer en ook niet minder.
-edit- dat deze vaak niet op kennis of bekwaamheid gekozen worden maar op basis van andere vaardigheden zal niet snel veranderen.
Had je overigens het idee dat dit tegenwoordig vaker voorkomt of dat je het tegenwoordig vaker tegenkomt? persoonlijk denk ik namelijk dat dit al sinds de middeleeuwen zo gaat.

[Reactie gewijzigd door Verwijderd op 29 juli 2024 19:38]

[Yezpahr]

-edit- dat deze vaak niet op kennis of bekwaamheid gekozen worden maar op basis van andere vaardigheden zal niet snel veranderen.
Had je overigens het idee dat dit tegenwoordig vaker voorkomt of dat je het tegenwoordig vaker tegenkomt? persoonlijk denk ik namelijk dat dit al sinds de middeleeuwen zo gaat.

Bedankt voor je reply en inzichten.
Het gelijkstellen is inderdaad misschien wat drastisch, maar zoals je in je edit aangeeft zijn die niet altijd zelf bekwaam met computers en IT. Juist vanwege dat punt heb ik het idee dat er iemand die wèl verstand heeft van die zaken ook een net zo'n hoog aanzicht te geven.

De CIO is een voorbeeld daarvan. Die moet nog steeds alles verantwoorden tegenover de CEO. Dat is begrijpelijk, maar als de CEO, met minder kennis, een opdracht op een bepaalde manier geeft en de CIO niet genoeg zeggenschap heeft om daar belangrijke (misschien wel wettelijk verplichte) toevoegingen aan te doen, dan gaan er onherroepelijk vaker dingen mis.

Dat was zo'n beetje mijn insteek

***EDIT***
Of het tegenwoordig vaker voorkomt lijkt me stug, met elk nieuwe bedrijvenbranche die ontstaan zijn wel kinderziektes die misbruikt worden, maar internet is op dit moment gewoon niet meer weg te denken uit een mensenleven terwijl de beveiliging van persoonsgegevens en privé-data niet gegarandeerd kàn worden.

Of dat by-design is is moeilijk te zeggen, maar het komt wel zo over imo.

[Reactie gewijzigd door Yezpahr op 29 juli 2024 19:38]

[Cronax]

In mijn ogen maak je een fundamentele fout: als jij als CIO je werk goed doet maar de CEO heeft het idee dat dat niet het geval is, dan heb je als CIO je CEO niet goed genoeg geinformeerd. Het is nu eenmaal een feit dat mensen in leadership rollen vaak niet op technische kennis geselecteerd worden maar op andere kwaliteiten, het is dus altijd de taak van de ondergeschikten om de mensen van het leadership goed te informeren zodat ze hun beslissingen kunnen baseren op de juiste gegevens.

Om op je voorbeeld in te gaan, als er een wettelijk verplochte toevoeging bestaat dan dien je dus als CIO je CEO te informeren dat deze verplichting bestaat en niet te omzeilen valt, vervolgens zal een goede CEO dat echt niet negeren...

[Punkbuster]

White head hackers lopen ook achter de feiten aan. Als je echt iets tegen hackers wil doen moet je ze inhuren/aannemen. Misschien een inside-man die op de legale manier geld wil verdienen

[mad_max234]

En je wilt dat soort gasten ver van je bedrijf weg houden! En zeker niet stimuleren. En wat heb je aan 1 hacker die weet ook niet alle lekken, je haalt alleen maar onbetrouwbaar persoon in huis en geen enkele garantie dat je systeem echt beter word. Of erger je word van binnenuit leeg getrokken omdat je hem zelf binnen heb gelaten.

Zet er gewoon eerlijke persoon op die geen hack verleden heeft, hackers zijn vaak niet eens de slimste mensen, hebben gewoon geen sociaal leven(op hun internet groepje na) en zitten vaak dag en nacht te zoeken bij honderden bedrijven , logisch dat ze wat vinden, niks knap aan.

[Cronax]

Niet gehinderd door enige kennis van zaken zie ik?

Je maakt een aantal stevige fouten. Het begint volgens mij met je definitie van 'hacken', hacken is niet alleen van toepassing op de computerwereld, het betekent zo veel als 'iets gebruiken voor een doel waar het niet strict genomen voor bedoelt is'. Wikipedia geeft een mooi voorbeeld: een wasknijper op je broekspijp steken om te voorkomen dat hij je ketting raakt en zo vies wordt is ook een hack, de wasknijper is immers bedoeld om was mee aan een waslijn/wasrek te hangen.

Je bedoelt waarschijnlijk mensen die via computers hacken, maar vervolgens generaliseer je die ook...die groep mensen is even divers als de 'normale' samenleving, het zijn echt niet allemaal criminele mensen met slechte lichaamshygiene die nooit slapen en overleven op koffie en fastfood. De meeste hebben gewoon een normale baan en vinden het leuk om in hun vrije tijd wat limieten op te zoeken van programma's, systemen, of beveiligingen.

Vervolgens vergeet je dat er allerlei soorten hackers zijn...Grofweg kan je alle hackers in 3 groepen verdelen, white hat, black hat en grey hat. Black hat hackers zijn uit op persoonlijk gewin of op aantasting van hun doelwit. Dit is waarschijnlijk het soort dat je bedoelt. White hat hackers willen alleen maar weten hoe iets in elkaar steekt en gaan vooral voor het gevoel, dit soort hackers zal een bedrijf dan ook vaak op de hoogte stellen als ze de beveiliging hebben kunnen omzeilen. Gray hat hackers vallen er een beetje tussenin, die gaan in eerste instantie voor dezelfde doeleinden als de White hat hackers maar willen hier en daar nog wel eens misbruik maken van hun kennis.

Ten slotte maak je een compleet verkeerde aanname, iemand die niets van hacken afweet zal ook nooit een adequaat beveiligingssysteem kunnen maken, net zo min als je een kogelwerend vest kunt maken als je niet weet wat de kracht is van de kogel die je wilt tegenhouden. Je wil er dus juist WEL mensen op zetten met een hack verleden hebben, omdat zij weten hoe een potentiele kwaadwillende zal proberen het beveiligingssysteem te omzeilen.

Om nog even in te gaan op je bewering dat hackers vaak niet de slimste mensen zijn, we moeten eerst al onderscheid maken tussen daadwerkelijke hackers en wat men 'script kiddies' noemt, mensen die een kant en klaar 'hackprogrammatje' downloaden en daar gebruik van maken vallen in die laatste categorie en zijn vaak inderdaad niet zo slim, maar om een systeem daadwerkelijk te hacken moet je wel degelijk inteligent zijn en een stevige dosis kennis in huis hebben...

[Patriot]

Zet er gewoon eerlijke persoon op die geen hack verleden heeft, hackers zijn vaak niet eens de slimste mensen, hebben gewoon geen sociaal leven(op hun internet groepje na) en zitten vaak dag en nacht te zoeken bij honderden bedrijven , logisch dat ze wat vinden, niks knap aan.

Zo, anders trek je even een blik rancune open ofzo

Ik heb zelf niks met black hat hacking te maken, maar zo'n beeld schetsen is iets waar je echt niets mee opschiet. Er zijn genoeg mensen met 'een hack verleden' die net zo'n goed moreel kompas als de rest van ons.

Negen van de tien keer (bwvs) is het sowieso meer gelegenheid dan de drang om iets 'slechts' te doen. Moet je eens kijken hoeveel zuiver goede mensen er over blijven als je ze de kans geeft om risicoloos iets te doen wat eigenlijk immoreel is.

[Verwijderd]

Inderdaad, hoe kun je nu iets van beveiliging weten zonder iets van aanvallen te weten, en hioe kun je dat nu goed beheersen zonder wat praktijk. uiteraard niet nodig om echte schade aan te richten, maar beveiligen en hacken lijken me onoverkomelijk aan elkaar verbonden.

ow en @Punkbuster,, spreek je jezelf niet tegen?
white head hat hackers lopen ook achter de feiten aan. Als je echt iets tegen hackers wil doen moet je ze inhuren/aannemen. Misschien een inside-man die op de legale manier geld wil verdienen
hacker weet het niet je moet de hacker inhuren?

-edit-
Het lijkt me inderdaad voor een bedrijf een "risk assessment" zoals hierboven is genoemd, maar met daarbij altijd een kosten / baten analyse.
Waarbij een waterdicht systeem (indien mogelijk) niet altijd het meest interessante zal zijn voor een bedrijf. (en/of de klant)

[Reactie gewijzigd door Verwijderd op 29 juli 2024 19:38]

[freaq]

een vriendin van mij had een laptop gekocht bij XXODD, deze ging failliet, een paar jaar geleden. ze had haar laptop geformatteerd en kon geen drivers vidnen want XXODD was failliet. ik gekeken bleek het een standaard clevo laptop te zijn.

ik naar de site van Clevo, resultaat je mag alleen drivers downloaden bij de manufacturer. die was dus failliet, na 3x te hebben gemaild was ik het zat en heb ik de drivers "gevonden" en gemirrord.

officieel zal dit niet mogen, maar dit sloeg gewoon nergends op.
hacken kan ook gebruikt worden om te helpen het is niet altijd meteen fout.

OT: lekker beeld schetst deze man ben verbaasd dat hij dit soort uitlatingen uberhaupt kan en mag doen gezien de toch zeer vertrouwelijke positie die hij hiervoor bekleede.
wel goed dat hij hier de aandacht op probeert te vestigen.

[Oerdond3r]

Meh nvm had niet gelezen dat het een reactie was betreffende black-hats

[Reactie gewijzigd door Oerdond3r op 29 juli 2024 19:38]

[J.J.J. Bokma]

Heren, als we dan al het hippe Engels continu op tweakers willen gebruiken, laten we het dan wel goed doen: White Hat. Het gaat om het hoedje ;-).

Enne, nee, wit wil niet zeggen dat je achter de feiten aanloopt. Hacken is een techniek, en de kleur van het hoedje (en dus niet het hoofd) wordt bepaald door wat je er mee doet.

[moreasy]

Precies:

White Hat : Hacker

White Head : Puistje

[Thunderhawk0024]

Ik heb anders buiten IT-sites zoals Tweakers nog niet vaak datalekken in het nieuws gezien...

[mad_max234]

Staan ook gewoon op sites als nu.nl, als grote lek is geweest dan staat het daar ook meestal gewoon. En op alle echte tech nieuwssites natuurlijk, daar word het standaard gemeld. Zoals slashdot.

[Reactie gewijzigd door mad_max234 op 29 juli 2024 19:38]

[Verwijderd]

Helemaal mee eens een doosje nanobot soldaten in je computer loslaten kan beslist geen kwaad

[Reactie gewijzigd door Verwijderd op 29 juli 2024 19:38]

[BrutalDave]

Wat zal hij bedoelen met 'het grote publiek', iedereen buiten de FBI, of alle niet Tweakers?

[Squ1zZy]

Ik zou zeggen "iedereen". Zelfs "Tweakers" hebben niet altijd alles op orde. Is het de taak van een systeembeheerder om alles up-to.date te hebben?

Ik heb een manager die niet eens weet wat het precies allemaal in houd. Ik kan niet verwachten van mijn manager dat hij mensen aan stuurt om alles up-to-date te hebben.

Penetration tests kosten geld. En veel ook tegenwoordig. Niet elk bedrijf kan dat betalen of kan het verkopen aan het management.

[.oisyn]

BrutalDave had het er natuurlijk over bij wie het bekend was, niet wie z'n zaakjes op orde heeft. Het slaat op deze opmerking uit het artikel:

De realiteit is dat het gros van wat gebeurt, niet wordt gehoord door het grote publiek

[Reactie gewijzigd door .oisyn op 29 juli 2024 19:38]

[qbert0]

Mijns inziens gaat de zin 'De realiteit is dat het gros van wat gebeurt, niet wordt gehoord door het grote publiek' over dat wat niet in de media komt. Bijna altijd worden incidenten bekent door klanten, door gebruikers of door de 'hacker' zelf. Je kan dus op je vingers natellen dat wij in alle andere gevallen niets zullen horen. Zo gaat alles perfect als er maar niemand op zit te letten.

[Verwijderd]

Waarom zet je hacker tussen aanhalingstekens ?
Op deze wijze miniminaliseer je het probleem, zelfs indien het scriptkiddies betreft.

[MrRobot]

Bedrijven nemen meestal security niet serieus, beschikbaarheid van de systemen zonder downtime voor patching e.d. wordt geeist van de beheerders.
Dan het liefst nog alle vertrouwelijke gegevens kunnen lezen op een iPad, want dat is zo makkelijk (terwijl de tablets uiteindelijk alleen maar worden gebruikt voor Hello Kitty Adventure Island door de kleine thuis).

Vervolgens bij een security incident direct de vinger naar de beheerders wijzen, want zij hadden het niet op orde blijkbaar.

[nwagenaar]

Het grootste probleem is niet dat de beheerders of het MT security niet serieus nemen, maar de hoeveelheid policies en compliances die door externe partijen worden verplicht (lees: regelgeving).

Door de enorme hoeveelheid regels - waarbij vaak een zeer klein gedeelte is gericht op de IT en/of security - wordt de focus vaak gelegd op verantwoordelijkheid en auditingmogelijkheden van de diverse processen en niet op de IT systemen zelf.

De regelgeving verandert zodanig en de hoeveelheid is zo groot dat ze amper genoeg tijd hebben om te kunnen voldoen aan de regelgeving. De IT-omgeving waar deze processen op draaien worden zeer beperkt ge-audit en al helemaal niet op gebied van beveiliging.

[xboxlivejunk]

Heb er eigenlijk nooit zo over nagedacht, maar logisch is het wel. Snap ook niet hoe sommige bedrijven er zo laks mee omgaan. Niet alleen de nieuwe systemen, maar ook de oude minder gebruikte systemen moeten dezelfde beveiligingen krijgen en houden, en niet dat er ergens nog een oud tabelletje online staat met oude achterhaalde encrypts. Als ik het zo hoor gebeurt dat nog veel te weinig. Wordt nu al moedeloos van elke dag een gehackte database, laat staan de rest van de ijsberg aanhoren. Ik hoef ook niet alles te weten, als ik er mijn gegevens niet heb staan.

edit: is toch gewoon on-topic?

[Reactie gewijzigd door xboxlivejunk op 29 juli 2024 19:38]

[- peter -]

Ik begin de laatste tijd wel het idee te krijgen dat we nog heel veel problemen zullen gaan krijgen. Software is mensenwerk, en omdat het theoretische constructies zijn zijn ze niet even dicht te timmeren zoals bij bijv. een winkel of huis wel kan. Daar houden de elementen je gewoon buiten. Dit is puur informatie. En eigenlijk is alles gewoon te hacken. Als dat een steeds grotere vlucht neemt, zou je zelfs kunnen verwachten dan computerbeveiliging zoveel gaat kosten dat mensen zich wat afkeren van de digitale techniek. Ik word er een beetje moedeloos van.

[Reactie gewijzigd door - peter - op 29 juli 2024 19:38]

[Fladder80]

Er zou ook gewoon meer getest moeten gaan worden op dit soort dingen. Sowieso merk ik vanuit mijn werk dat bijna geen enkel bedrijf zijn software laat testen of ook maar enige ervaring met het laten testen heeft. En zelfs dan wordt er niet eens gevraagd om te testen op veiligheid. Nou is dat natuurlijk ook aan ons testers om dat aan te bieden, maar als de klant het belangrijker vind dat we het product op 10 verschillende platformen testen op usability en we daar krap tijd voor krijgen, dan houdt het natuurlijk ook op.

[Will_M]

En dan heb je dadelijk je "software" waterdicht/up-2-date, loop je weer "gewoon" tegen een fysiek lek aan.

Social Enginering is oude toekomst?