Politiebond haalt site offline na hack

De website van de Politiebond kampte met een kwetsbaarheid waardoor onder andere loginnamen en wachtwoorden konden worden buitgemaakt. De Politiebond werd dinsdag al getipt, maar wist het lek pas een dag later te dichten.

Dinsdagmiddag werd Tweakers.net getipt over een beveiligingslek in de website van de Nederlandse Politiebond, een vakbond voor medewerkers van de politie. Het bleek mogelijk om op een bepaalde pagina aan een variabele eigen sql-queries toe te voegen. Dit type beveiligingsprobleem, beter bekend als een sql injection-kwetsbaarheid, komt vaak voor.

De Politiebond beloofde Tweakers.net het lek zo snel mogelijk te dichten. Woensdagmorgen, toen andere media al over het beveiligingsprobleem gepubliceerd hadden, bleek het beveiligingsprobleem echter nog steeds te bestaan.

Een ontwikkelaar die in opdracht van de Politiebond werkt, Ron Rutten, beweerde tegenover Tweakers.net dat het beveiligingsprobleem was opgelost. "Alle variabelen worden opgeschoond met de mysql_real_escape_string-functie", aldus Rutten. Die functie is bedoeld om variabelen op te schonen voordat ze in een sql-query worden gebruikt.

Toen Rutten werd verteld dat het manipuleren van sql-queries nog steeds eenvoudig mogelijk was - wat er op duidt dat de betreffende functie niet of onjuist wordt gebruikt - beloofde de ontwikkelaar om nogmaals naar het probleem te kijken.

Een uur later is de gehele website van de Politiebond uit voorzorg offline gehaald. Daarmee kon echter niet worden voorkomen dat een gedeeltelijke dump van de database, met lidmaatschapsnummers, namen en wachtwoorden, op Pastebin verscheen.

Volgens Rutten gaat het daarbij gaan om gegevens uit een oudere database, voor een webapplicatie die niet meer werd gebruikt. "Deze applicatie is ooit online gezet en vervolgens niet meer bijgewerkt", aldus Rutten. Volgens hem gaat het om een database die dinsdag al offline is gehaald en die los stond van de huidige website. Dat komt niet overeen met de bewering van de hacker, die stelde dat de kwetsbaarheid op de nieuwspagina kon worden gevonden. De kwetsbaarheid zit volgens Rutten in ieder geval niet in een verouderde versie van MySQL, zoals andere media meldden.

Het is onduidelijk wie het beveiligingsprobleem ontdekte en de database-dump heeft gepubliceerd. Volgens een bron van Tweakers.net is dit het werk van een hacker die contact heeft met de 'hackersgroep' Anonymous, maar het losvaste verband zou er verder niets mee te maken hebben.

Afbeelding: XKCD

Reacties (77)

Ik herinner me dat ik vijf jaar geleden mysql_real_escape_string heb laten vallen ten faveure van prepared statements of beter omdat het gewoon geen goede beveiligingsmethode was van queries.

Beter dan ik het kan zeggen:

http://stackoverflow.com/...-php-code-safe-from-injec

Sowieso is het nadeel in PHP dat je een integer altijd moet checken voordat je hem gaat gebruiken in je code. .Net code klapt er gewoon uit of geeft 0 terug als je een int wilt halen uit een request parameter.

[Reactie gewijzigd door BikkelZ op 6 juli 2011 13:23]

Simpele oplossing:

$integer = (int) $_GET["integer"];

Forceerd namelijk dat de variable een integer is.
Dus ik snap je punt niet helemaal.

Dan kunnen ze van alles proberen om er een string van te maken, de (int) forceerd de variable gewoon een INTEGER is, en niks anders dan dat.
Als er string data gestuurd word, word het automatisch 0.

[Reactie gewijzigd door Anoniem: 268141 op 6 juli 2011 14:02]

Goede gegevensvalidatie wordt erg onderschat.
Als je een veld verplicht maakt check dan ook wat basis data... verwacht je een integer maar je variabele dan een integer. Verwacht je een mailadres check dan met een reg ex de opmaak... et cetera

En dan ook nog zo iets attempts meten: als iemand 4 keer een formulier of veld aan het invullen is met continu fouten: blokeer het ip met een time-out. Genoeg open mailformuliertjes zonder attempt/usage meting... dat is simpelweg vragen om gedonder.

Ook snappen veel beheerders niet dat sql ook werkt met users. Een rapportagefunctie van een site hoeft vaak alleen gegevens te lezen. Laat die query dan ook uitvoeren door een sql gebruiker met alleen leesrechten. Wil je iets loggen: aparte gebruiker met alleen rechten voor de table voor logs (en dan grotere rechten als drop en create gewoon uit laten).

Als je basisregels als niet toepast hoe kan je dan nog veiligheid van je gegevens garanderen.... ik snap ook niet waarom het bij dit soort sites toch nog fout gaat. Iemand heeft dan wel onzettend de kantjes eraf gelopen....

Die zogenaamde hackersgroepen hebben echt geen idee wat ze aanrichten en wat een onkosten ze maken. Die hebben geen zorg in de wereld en vinden het "gewoon leuk" om alles plat te leggen. "Well done boys!"
Het gaat er al lang niet meer over dat ze willen aantonen hoe slecht de beveiliging is, dit begint op pure criminaliteit te lijken, als het al niet zo is.
Wees dan een vent en ga die bedrijven adviseren als je het allemaal zo goed weet, zo houd je er zelf ook nog iets aan over.

[Reactie gewijzigd door BlueLed op 6 juli 2011 12:07]

Het probleem tegenwoordig is dat als men niet aantoont wat het risico is, maar alleen een advies geeft over slechte beveiliging, er simpelweg niets aan gedaan wordt. Zal wel los lopen, zeggen de managers dan. Veel te duur om te maken. Wie wil ons nou hacken? Is wel goed zo toch? Tegen die tijd zien we wel.

Die zogenaamde website bouwers/beheerders hebben echt geen idee wat ze aanrichten en wat een onkosten ze maken. Die hebben geen zorg in de wereld en vinden het online mikken van een website "gewoon leuk en handig".

Dat is wat er in je reactie had moeten staan. Het is in dit geval de politiebond die een website exploiteert en hiervoor logins gebruikt. Zij zijn net als ieder ander die zoiets doet wettelijk verplicht om correct met gegevens om te gaan. Dat betekent dat zij deze dan ook moeten beveiligen. Iets simpels als een sql injection laat zien dat hiervan geen sprake is geweest. Zowel het OM als het CBP zou het sieren als men hier dan ook onderzoek voor vervolging instelt.

Daarnaast dienen zij datzelfde te doen voor de hackers. Zij hebben sql injection gebruikt en gegevens afhandig gemaakt welke vervolgens zijn gepubliceerd. Ook dat is bij wet verboden.

Kortom, allemaal boehoe en huilie dat hackertjes vervelend doen maar uiteindelijk zijn zij niet degenen die een site online zetten, daar persoonlijke data bij achter gooien. Dat is de exploitant zoals een bedrijf, instelling, overheidsorgaan, etc. Zij ontlopen al jaren de wettelijke verplichting om goed voor dit soort data te verzorgen. Het wordt nu echt eens tijd dat de overheid dat nou eens duidelijk gaat maken door hier tegen op te treden. Dat optreden betekent dus vervolging wegens overtreding van de WBP en WCC. Laat het heel duidelijk zijn dat het hier NIET om gegevens gaat van de exploitant van de website maar om andermans gegevens. Die mensen denken dat ze het in goede handen hebben achtergelaten. Dat vertrouwen wordt bij dit soort zaken doorbroken en dat is een vele malen ernstigere situatie dan een paar hackertjes die vervelend doen.

Edit: bij Bits of Freedom hebben ze een aparte categorie voor dit soort problemen. Die houden een soort van blacklist bij van bedrijven waar je gegevens door dit soort domme foutjes (sql injection, niet gebruik van het bcc veld, etc.) niet in goede handen zijn.

[Reactie gewijzigd door ppl op 6 juli 2011 14:39]

Inderdaad: security through obscurity is een veel veiliger security-model!

Ik ben ook tegen publicatie van onschuldige accounts, maar er wat wat af-geamateurd op het Internet, dat vind ik mogelijk nog erger.

[Reactie gewijzigd door haling op 6 juli 2011 12:10]

Geeft niemand het recht om er misbruik van te maken. Als ik een verouderd slot in mijn deur heb, wil dat niet zeggen dat mensen het zomaar mogen openbreken en mijn spullen mogen stelen. Als ze me gewoon zeggen dat het slot verouderd is en dat mijn spullen wellicht gestolen kunnen worden, heb ik er toch wel meer respect voor.

dit komt zoveel terug, he
ik heb in mijn wilde jaren (ahum) dat verschillende keren gedaan: mensen gewezen op hun beveiligingsfouten.... dat is mij verschillende keren zuur opgebroken (bijna job en proces gekost).

Misschien tijd voor eens een t.net poll: hoeveel mensen zouden "the messenger" vervolgen, bedanken, ... ? Aan de reacties op dit soort onderwerpen zie je dat velen "the messenger" doodschieten...

Geloof mij, dan leer je dat "gewoon zeggen" wel af... wat je dan WEL doet... laat ik in het midden, maar het kan maar 2 kanten uit:
1. je stopt en zegt niets (bug blijft)
2. je doet het "the evil way" en vindt/misbruikt de bug van punt 1

dus hoe je het ook draait of keert: 2 is ALTIJD de uitkomst zolang "the messenger" niet de enige juiste manier is...

Zou je anders niet een 3de manier hebben dan?

Gewoon aan Tweakers.net( of een andere vertrouwde techsite) aangeven dat er ergens een bug te vinden is en dat zij dan voor jou contact opnemen met hen, zodat zij meteen naar hun fouten kunnen kijken.

Het beste zou zijn dat er een legale door de overheid gesteunde instelling tot leven wordt gewekt om dit soort problemen anoniem te kunnen doorspelen via die instelling aan bedrijven,etc zodat de instelling dus de bedrijven kan waarschuwen en op de vingers tikken als het te lang duurt.

Misschien zelfs een boete schrijven, maar daarvoor hebben we eerst nog wetten nodig etc. Dus ik zie dit liever gebeuren door een instelling die door de overheid bevoegd is te opereren en dat er duidelijke en nieuwe wetten worden aangenomen.

Helaas weten we allemaal al te goed hoe er met ICT wordt omgegaan door de overheid en helemaal door al die bedrijven.

Geeft niemand het recht om er misbruik van te maken. Als ik een verouderd slot in mijn deur heb, wil dat niet zeggen dat mensen het zomaar mogen openbreken en mijn spullen mogen stelen. Als ze me gewoon zeggen dat het slot verouderd is en dat mijn spullen wellicht gestolen kunnen worden, heb ik er toch wel meer respect voor.

Erger vind ik dat mensen een beetje lui worden en af en toe moeten ze even wakker worden geschud.. Ze hadden het gewoon gelijk moeten fixen... Maar waarom moeite doen he...
Ik heb al vaker mailtjes gestuurd ivm de beveiliging maar meestel zeggen ze dan ja maar.. of helemaal geen reactie.. Of erger nog het zal niet zo vaart lopen...

[Reactie gewijzigd door demilord op 6 juli 2011 12:20]

Niemand zegt dat het mag. Niemand zit er op te wachten, maar het gebeurd en dus moet je je verantwoordelijkheid nemen...

Er zijn nou eenmaal een aantal dingen in de wereld die gewoon gebeuren ook al ben je er tegen of het niet mee eens, daar moet je dus correct mee handelen...

Je gaat nu toch ook niet naar Libië op vakantie, als er dan een bom op je hoofd valt is het niet jouw schuld maar wel gewoon DOM want je weet dat dat kan gebeuren
Je laat je voordeur toch ook niet open staan als je niet thuis bent?
Je laat je (beveiligde)website toch ook niet open staan zodat iedereen er bij kan?
Enz...

Tuurlijk kost dit bedrijven een hoop geld, maar als ze goed beveiligd hadden had het ze een stuk minder gekost, oftewel hoop dat bedrijven/overheden/stichtingen hier wat van leren!

Tja, het is maar net wat je hacken noemt. Een SQL injectie is kinderlijk eenvoudig en er staat genoeg beschreven op het internet hoe dit werkt.

Voorbeeld en nog een

Wat die mensen doen is waarschijnlijk net zolang websites afzoeken op het internet totdat ze een lek vinden. Zou me niks verbazen als ze al bij honderden websites een poging tot een SQL-injectie hebben gedaan.

[Reactie gewijzigd door SpaceK33z op 6 juli 2011 12:08]

Goed, hoe je het ook noemt, ik kan jou ook uitleggen hoe je een winkel kan overvallen en hoe je het meeste inventaris weg kunt roven om het vervolgens op een zwarte markt te kunnen verkopen. Want dat is zo'n beetje wat ze hier virtueel doen.

[Reactie gewijzigd door BlueLed op 6 juli 2011 12:14]

dat is waar... Vroeger kon iedereen gewoon de winkel binnen wandelen en meepakken wat ie wou, want er waren geen sloten op de deuren.
Nu weet iedereen dat hij zijn deuren moet sluiten en doet iedereen dat ook.
Alleen weet niet iedereen op internet dat een "slot op de deur" handig kan zijn. En dan maar wenen als er ingebroken wordt...

Wederom:
als bugs algemeen bekend zijn, heb je GEEN reden om NIET te patchen. SQL injections en remedies bestaan al jaren, dus daar fouten in maken is in mijn ogen hetzelfde als je deuren en ramen open laten staan.

Wederom:
als bugs algemeen bekend zijn, heb je GEEN reden om NIET te patchen. SQL injections en remedies bestaan al jaren, dus daar fouten in maken is in mijn ogen hetzelfde als je deuren en ramen open laten staan.

Technisch gezien heb je helemaal gelijk. Maar in de praktijk gaat zoiets (volgens ITIL) naar een Change Advisory Board. Die moeten dan eerst gaan overleggen of en waarom het nodig is. Dan wordt en gevraagd aan b.v. applicatie beheer om eerst een paar keer te testen wat het effect is op de (overige) applicaties (misschien werkt pakket A juist wel met SQL injectie richting pakket B intern b.v.) en dan moet alles nog ingeplanned en uitgerold worden. Planning, kennis en geld. Drie zaken die ze bij de overheid dus niet hebben en dan wordt er vaak gezegd "if it aint broke, don't fix it". Ben het er niet mee eens, maar zo krijg je dus dit soort situaties.

Bij dit soort publieke websites mag ik toch hopen dat er gewoon een incident wordt aangemaakt waarmee als de donder de site offline wordt gehaald en een ontwikkelaar er aan de haren bij wordt gesleept om het probleem te fixen. Dit is natuurlijk wel afhankelijk van degene die de ernst van het probleem inschaalt, als die te weinig kennis hebt, dan doe je er weinig meer aan.

ITIL is prachtig, maar pragmatisch werken is beter

@BlueLed, het is al zo vaak gezegd: als het kan, dan gebeurt het ook. Je kunt je wel heel boos maken over het onrecht wat hier geschiedt, je kunt er ook voor kiezen om de beveiliging goed te regelen zodat dit niet meer voor kan komen. En misschien moeten bedrijven maar een met de neus op de feiten worden gedrukt, namelijk dat ze onkundig en ongekwalificeerd (maar wel goedkoop!) personeel in dienst hebben, hoe vervelend dat voor de betrokkenen ook is. Of dat een leidinggevende structureel verkeerde beslissingen heeft gemaakt. Dat is met name een kwalijke zaak als er gegevens van derden in die databases zitten (zoals de vele Pastebin dumps hebben aangetoond). Dit zijn geen kwaadaardige hackers en criminelen, maar verontwaardigde users die op een werkelijk té simpele manier een site kunnen binnenwandelen.

[Reactie gewijzigd door TDeK op 6 juli 2011 12:40]

Het ergste is dat meestal dit personeel juist niet goedkoop is.

Echter mysql_real_escape_string gebruiken in plaats van parameters is gewoon broddelwerk. Echter zolang bijvoorbeeld de politiebond de kosten (ook die van imago schade) niet verhaald op de programmeurs zal je namelijk altijd dit soort slordigheden houden. En als een SQL injectie mogelijk, dan loert de XSS-injectie ook vaak om de hoek..

De politiebond is geen expert in development. Als jij een bedrijf inhuurt, mag je verwachten dat deze verstand van zaken heeft. Net zoals een taxi chauffeur de weg hoort te kennen, horen developers gewoon op de hoogte te zijn van best practices, anti-patterns en design-patterns..

Het is heel belangrijk hoe je dit noemt

Dit is een programmeer fout... Ik vind dat je niet over beveiliging kan praten wanneer je de deur open laat.

Alleen al een kleine controle op de ingevulde karakters in een veld voordat deze variables in je query terecht komen scheelt al enorm... mysql_real_escape_string gebruiken in je query kan handig zijn maar voorkomt idd niet alles... Volgens mij escaped hij de "gevaarlijke" karakters maar kan de hacker deze escapes voorkomen (alhoewel ik dit niet zeker weet)

Dit staat nog los van de oplossingen die hieronder genoemd worden mbt prepared statements wat een professional sowieso zou moeten gebruiken IMO

[Reactie gewijzigd door Mellow Jack op 6 juli 2011 13:14]

Even kort door de bocht, en dan met name op dit beveiligingslek gebaseerd:

Heb jij ooit een supermarkt gezien zonder een muur/beveiliging er om heen? Daar weet je ook zeker van, dat hij 's nachts leeggeroofd is. En in principe concludeer ik dit ook uit de website van de politiebond, gewoon slecht beveiligd.

Toch intressant dat de politie bijvoorbeeld wel bij woningen "inbreekt" om de kwetsbaarheden aan te tonen. Dat voorbeeld volgt men gewoon

Dus het is maar met welke intentie het wordt gedaan.

In je eerste zin heb je het voer hackers die alles maar platleggen en schade aan richten.

Ik heb liever dat alle sites goed aan test worden onderworpen door "hackers" want blijker kunnen organisaties en geen goede/velige sites maken en ze goed laten testen door experts

Het publisheren is idd behoorlijk laakbaar, maar ze ziet aan de reactie dat de publicatie pas plaats vond nadat men melde het probleem te hebben opgelost, en het daarna nog steeds mogelijk was. Dat is ook behoorlijk laakbaar te noemen

Wees blij dat deze hacks openbaar gemaakt worden. Als deze hackers het kunnen, kunnen chinese hackers het ook.

Eigenlijk tonen ze alleen maar aan dat er grote beveiligingslekken in zitten. Het is eigenlijk best beroerd hoe slecht het op het moment is met de beveiliging van veel overheidsites.

tja, het is meer een beetje van allebei, hoe kan het zijn dat men totaal geen aandacht aan het beveiligen van mogelijkerwijs waardevolle (of gevoelige) gegevens besteed en dat men een week normaal vind om dat soort slack op te lappen..

Nu gebeurd er wat, sterker nog, ik vind al die crackers wel handig in een tijd waarin cyberwar achtige scenario's steeds meer een risico worden...

Liever nu nat gaan dan als er echt iets aan de hand is.

[Reactie gewijzigd door blouweKip op 6 juli 2011 17:12]

Die zogenaamde hackersgroepen hebben echt geen idee wat ze aanrichten en wat een onkosten ze maken.

Die kosten moeten toch gemaakt worden; als je er niks aan doet kan iedereen met slechte bedoelingen zo naar binnen wandelen. Dat vind ik dus eerlijk gezegd een onzin-argument.

Het probleem van computerbeveiliging is, mijns inziens, dat het niet duidelijk te zien is of je het goed gedaan hebt. Als je je voordeur van papier en karton maakt dan ziet iedereen meteen dat er een probleem is. Maar (de code voor) een website die vatbaar is voor SQL-injectie kan er op het eerste gezicht prima uitzien. Iemand kan de beste bedoelingen hebben en een prima programmeur zijn, maar als ie niet weet waar ie op moet lekken kan er een enorm gat in de beveiliging zitten.

Een, mogelijk gerelateerd, probleem is dat de mensen die over het geld gaan vaak geen al te hoge prioriteit lijken te geven aan digitale beveiliging. Dus als je alleen meldt dat er een probleem is, dan wordt er (tenminste, die indruk lijken veel mensen te hebben) gewoon lekker niets mee gedaan. Helaas lijkt het erop dat je wel publiekelijk zult moeten aantonen dat je inderdaad binnen bent geweest om de eigenaar genoeg voor schut te zetten dat er wel iets mee gebeurt (en anderen, met mogelijk echt slechte bedoelingen, ook niet meer binnenkomen!!). Alleen, dan ben je dus wel strafbaar...

Die zogenaamde hackersgroepen hebben echt geen idee wat ze aanrichten en wat een onkosten ze maken. Die hebben geen zorg in de wereld en vinden het "gewoon leuk" om alles plat te leggen. "Well done boys!"
Het gaat er al lang niet meer over dat ze willen aantonen hoe slecht de beveiliging is, dit begint op pure criminaliteit te lijken, als het al niet zo is.

In wat voor manier leggen zij die site plat? Op wat voor manier zijn zij crimineel?

Heb je dan liever dat ze niets doen en dat het boevengilde dit allemaal ongemerkt doet? Want geloof me: voor elke hacker die dergelijke problemen naar buiten brengt zijn er 10 die zulke databases voor eigen gewin aan het minen zijn.

Wees dan een vent en ga die bedrijven adviseren als je het allemaal zo goed weet, zo houd je er zelf ook nog iets aan over.

Je ziet zelf dat de ontwikkelaar niet weet waar het probleem ligt. Dergelijke mensen moet je aan het handje nemen om de problemen te laten zien. Verder werkt een bepaalde omgeving ook veel stimulerender. En een corporate omgeving is dat dus niet.

Weer een erg kinderachtige actie. Beveiligingslekje zoeken, gegevens downloaden en plaatsen op een of andere website. Wat mij betreft geen heldendaad maar gewoon diefstal.

Nou nou,

Kijk, het hele probleem is dat netwerken redelijk obscuur zijn.
Je kunt het niet zomaar zien, je kijkt tegen een wolk aan.
Hierachter kunnen mensen hun fouten in securitydesign verstoppen (security by obscurity).
Gewone mensen boeit het echt niet, die zien het niet en die snappen het niet.
Maar een SQL-injectie lek is echt not done in de echte wereld.
Het is namelijk een erg makkelijk uit te buiten zwakheid die makkelijk te voorkomen is.
En het is in ict-land algemeen bekend dat dit fenomeen zich voordoet.
Een ingehuurde hacker heeft dit in no time door.
En dan praten we over de databases van de politiebond. Daar staan veel gegevens die criminelen in handen willen hebben.
Denk daarbij aan mensen die hetzelfde (usernaam en) wachtwoord gebruiken voor andere systemen, dan ben als hacker je opeens hoofdinspecteur op het politienetwerk ofzo.
Deze gegevens zijn waarschijnlijk al enige tijd in omloop in het criminele cirquit, zoals zoveel zaken.
Magoed, de gewone man ziet het niet en boeit het niet.

Dus moet het toch echt een keer fout gaan voordat de put gedempt wordt (lek gedicht).
En dan vind ik dit nog een soort van gecontrolleerd afdwingen van het oplossen van dit probleem.

Blijkbaar was dit lek al een tijdje aanwezig.
Hoeveel criminelen hebben zich al tegoed kunnen doen aan de informatie in deze database?

Het probleem is over het algemeen dat mensen gewoon uitgaan van security by obscurity. Zolang niemand het weet, deert het niet.
Dat is goedkoper, je hebt er minder mensen met skills voor nodig en je hoeft er niet over na te denken/pplan maken etc.
Dus wat gebeurt er in nederland (en niet uitsluitend in nederland natuurlijk), er wordt gewoon aangeklooid.
Zolang het goed gaat gaat het goed en grote kans dat de bedenker allang vertrokken is voordat er problemen komen.
Uiteindelijk is niemand echt verantwoordelijk en als ze de problemen in een doofpot kunnen stoppen dan gebeurt dat ook en gaan ze vrolijk verder.

Wij als burgers mogen best verwachten dat onze overheid een goede beveiliging in acht neemt in onze snel ontwikkelende computerwereld.
Dat gebeurt te weinig en er is niemand die dat af kan dwingen.

Daarom hulde aan de hackertjes die laten zien hoe ontzettend onze overheid aan het falen is op ICT beleid.
Dit voorval geeft gewoon aan dat ze het proces niet beheersen en dus blijkbaar niet de juiste eisen kunnen stellen aan zelfs een website.
Wat mogen we dan wel niet verwachten van de andere systemen binnen de overheden?

Daarom hulde aan de hackertjes die laten zien hoe ontzettend onze overheid aan het falen is op ICT beleid.

Is niet echt overheid gebonden, of heb je het recente nieuws niet gevolgd (psn etc)

Overigens is de kaalslag bij de overheid die vanuit het conservatieve dogma wordt doorgevoerd direct de oorzaak van dit soort problemen, minder kunde en tijd om dat soort zaken te regelen en managers worden alleen afgerekend op KPI;s die hier niets mee van doen hebben.

Vind ik ook, en probeer die knakkers dan maar eens op te sporen.

Echt, in welk jaar zullen we eindelijk eens verlost zijn van SQL Injections?!? Ik kan er gewoon niet bij dat dit in 2011 nog steeds plaats vindt.

Maar goed, zo lang mensen nog voor een dubbeltje op de eerste rij willen zitten, zullen beunhazen die dit soort prutswerk afleveren blijven bestaan.

Ook in PHP zijn er prima manieren om dit tegen te gaan dus het ligt niet aan de taal of het platform maar puur aan de onkunde van degene die dit gemaakt heeft.

@Vastloper: Ik kan nu een hele mooie (en ook lange) discussie beginnen over legacy en technological debt maar dit lijkt me niet de plaats. Waar gehakt wordt, vallen spaanders en om uiteenlopende redenen wordt in de ICT zelden iets in 1 keer helemaal goed gebouwd. Dat is helemaal niet erg als je er maar bij stil staat. Ik maar onderdeel uit van een bedrijf dat klanten adviseert bij het laten bouwen of aanpassen van applicaties en systemen. Het up-to-date houden van systemen (zowel nu als ook in de toekomst) is zeker een aandachtspunten in onze adviezen. En dat hoeft zeker niet te betekenen dat er elk jaar een complete rebuild plaats hoeft te vinden... maar af en toe een goede refactoringslag kan geen kwaad.

[Reactie gewijzigd door sys64738 op 6 juli 2011 14:10]

Wat dacht je van het feit dat bedrijven verouderde software decenia blijven gebruiken omdat de originele programeur er niet meer werkt of niet meer te bereiken is of simpelweg een stagiair was. Of wat dacht je van ingekochte 3rd party software waarbij het bedrijf niet meer bestaat of is overgenomen? Denk je soms dat alles wat op het web staat in 2011 is geschreven??? Je wilt niet weten hoeveel oude software nog steeds gebruikt word. Gelukkig nog het meeste daarvan achter gesloten deuren.

[sarcasme] Ik ga ervan uit als jij ooit een bedrijf begint in software of websites, je geld reserveert om je alsmaar groeiende softwarecollectie jaarlijks compleet te herschrijven..... [/sarcasme]

Ook in PHP zijn er prima manieren om dit tegen te gaan dus het ligt niet aan de taal of het platform maar puur aan de onkunde van degene die dit gemaakt heeft.

PHP is easy to misuse and hard to use qua MySQL queries. Precies het tegenovergestelde van wat het zou moeten zijn...

Maar ja, PHP devs en veel 'tweakers' zijn van mening dat er geen enkele reden is daar iets aan te veranderen.

[Reactie gewijzigd door Olaf van der Spek op 6 juli 2011 13:31]

Het maakt niet uit welke taal je gebruikt.
Als je de data rechtstreeks in de query plaatst vraag je om problemen.

Het maakt niet uit welke taal je gebruikt.

Dat is niet waar, sommige platformen hebben query builders die wel safe zijn.

Maar ik vraag me soms wel af is mysql_real_escape_string wel genoeg tegen injecties?

Ja en nee. Het is te eenvoudig die functie een keer te vergeten, dus daarop vertrouwen is niet slim.

Zo kun je alles wel als onveilig bestempelen...

JA, mysql_real_escape_string is 100% perfect tegen mysql injecties.

Ik werk als 10 jaar met mysql en ben het nog nooit "vergeten".

Ik werk als 10 jaar met mysql en ben het nog nooit "vergeten".

Good for you. Maar daar hebben anderen niks aan.

Nee, mysql_real_escape_string is niet 100% perfect tegen mysql injecties. Wat nogal eens gebeurt is dat een query er uit ziet als SELECT * FROM table WHERE id = $id

Als er geen aanhalingstekens om $id staan dan werkt de query perfect, kun je mysql_real_escape_string gebruiken zoveel je wilt, maar je site is wel kwetsbaar voor sql-injecties.

Het is duidelijk nu een hobby geworden voor veel mensen om zoveel mogelijk sites in het nieuws te krijgen. Op zich ben ik er geen voorstander van, al helemaal niet wanneer persoonlijke gegevens worden vrij gegeven, maar als dat niet gebeurt is het wel interessant. Ik denk dat dit een periode is waarbij we grote investeringen kunnen verwachten door alle bedrijven met gevoelige data, wellicht dus positief als dit betekent dat ze "volwassen" worden.

mysql_real_escape_string? Parameterized queries lijken me een veel robuustere oplossing, dan gaat het altijd goed.

Neem aan dat je prepared statements bedoeld? Als je iets te escapen hebt (met mysql_real_escape_string) dan heb je ook een parameter in je query zitten lijkt me zo.
Maar inderdaad met PDO is een hoop ellende te voorkomen en het lijkt ook meer op het model wat in andere programmeertalen wordt toegepast.

Kan trouwens wel andere problemen opleveren zodat het toch nog niet 'altijd goed' gaat. Onlangs nog ellende gehad met versieverschillen van SQLite, werkt de database niet op de host omdat die een andere versie van sqlite draait die nog geen foreign keys ondersteunt *zucht*.

http://maxcdn.fooyoh.com/...4/for_traffic_cameras.jpg

Deze zin klinkt meer om aan te geven "dat het niet zo erg" is.
"Deze applicatie is ooit online gezet en vervolgens niet meer bijgewerkt"

Ik vind dat Ron Rutten een grote fout heeft gemaakt.

Wat ik dan weer niet snap is dat de SQL Injection nu wel bekend zou moeten zijn bij de meeste ICT'ers. Waarom worden de sites niet gechecked door beheerders of ze kwetsbaar zijn hiervoor?

Inloggen met: ' or 1=1 -- bijvoorbeeld om te kijken of je kwetsbaar bent. Of ID=' in de URL.

Er is genoeg informatie te vinden over de SQL Injection om te kijken of de site die je beheerd of bezit bestand zou moeten zijn voor de simpele SQL Injection.

Google gebruiken met inurl id= en een SQL Injection toepassen wordt zo wel heel makkelijk.

Er zijn zelf tools zoals Havij maken het wel heel simpel deze dagen
http://itsecteam.com/en/projects/project1.htm

Ik moet zeggen dat deze dump toch niet echt veel voorstelt. Kijk zelf maar.
http://pastebin.com/pgA4JMxt

Wat me wel weer opvalt is de "sterke" wachtwoorden die er gebruikt worden. zoals toossmit
Leren ze het dan nooit.

ehm... toossmit lijkt me de username, wat voor de : staat lijkt me de password-hash.

nope dat is het password. Hash 'toossmit' maar eens