Loginformulier Kluwer Software te omzeilen via sql-injectie

Softwareleverancier Kluwer had zijn website niet goed beveiligd. Met een simpele sql-injectie kon het loginscherm voor klanten worden omzeild. Gegevens van tienduizend klanten konden daardoor worden benaderd.

Door in het wachtwoordveld van de Belgische vestiging van Kluwer Software de string ' or 1=1-- in te voeren, kon het loginscherm worden omzeild. Het gaat om een basale beveiligingsfout. Tweaker Tharulerz meldde de kwetsbaarheid bij Tweakers.net, waarna Kluwer Software, onderdeel van de multinational Wolters Kluwer, werd ingelicht. Binnen een uur na de melding werd de kwetsbaarheid opgelost.

"We hadden de maximale wachtwoordlengte aangepast naar twaalf tekens om dit soort aanvallen te voorkomen", zegt George Jans, de webmaster van Kluwer Software. Dat was in dit geval niet voldoende, omdat het om een string van tien tekens gaat. Bovendien is het beperken van de lengte van wachtwoorden twijfelachtig, omdat dat ook de sterkte van de wachtwoorden aantast.

Eenmaal ingelogd kon een kwaadwillende patches downloaden en privégegevens van de geregistreerde gebruiker inzien. De user-id's waren oplopend en elke willekeurige id die Tharulerz invulde, werkte. De database zou 40.000 klantgegevens bevatten; webmaster Jans houdt het op 10.000.

Hoewel de kwetsbaarheid behalve tot adresgegevens geen toegang gaf tot gevoelige informatie, maakt het feit dat het om een simpele sql-injectie gaat, de kwestie pijnlijk voor een grote softwareleverancier als Kluwer.

Reacties (101)

En dan verzwijgen we nog even het feit dat in de link om uit te schrijven van hun nieuwsbrief je username en password in plaintext in de GET parameters vermeld staan...

Allemaal vrij onvoorstelbaar komende van een softwarebedrijf.

Je snapt ook eigenlijk niet dat dit soort bedrijven niet de media volgen en het is ronduit raar dat er niemand van de IT afdeling opstaat en de software ontwikkelaars vraagt hun geschreven code na te kijken.

Ehm een groot international bedrijf...

Uit eigen ervaring, het bedrijf waar ik werk heeft ongeveer 40.000 domein namen in de centrale database (de locale sites in landen die niet onder het centrale gezag vallen zijn daar niet in mee genomen). Zelfs als er al iemand opstaat en roept we moeten iets aan site X doen dan nog is er totaal geen verschil op het geheel....
Sommige sites zijn letterlijk tien of meer jaren oud en draaien waarschijnlijk nog vele tientallen jaren voor iemand tot de ontdekking komt dat ze eigenlijk niet meer echt gebruikt worden.

Als je het over een klein bedrijf hebt met een paar sites dan is het goed te doen om even de ontwikkelaars te vragen hier iets aan te doen, maar als je kijkt naar het bedrijf waar ik werk daar hebben we op dit moment ongeveer 50 mensen binnen de security afdeling die zich met IT bezig houden. Deze mensen kunnen onmogelijk alle duizenden sites testen op gaten die er ongetwijfeld in zitten. Het is dus simpel weg een kwestie van tijd voor iemand een gat vind en zich een weg naar binnen weet te banen. Om die reden ook wordt er minimaal net zo veel aandacht besteed aan de achterkant van de systemen om te voorkomen dat naast klant gegevens ook bedrijfs geheimen uitlekken.

Er is maar een echte oplossing voor dit soort dingen en dat is de IT een heleboel professioneler aanpakken. Op dit moment kan iedere aap met een toetsenbord en een search engine zich na een paar weken al een php/mysql developer noemen. Geef ze nog een half jaar en ze zijn binnen veel bedrijven al door gegroeid naar medior developer... Dat is vragen om problemen...
Opleidingen zijn om te lachen zelf helaas geld besteed aan een HBO opleiding op IT vlak maar daar niet een enkel vak kunnen vinden waar men zich bezighield met beveiliging of veilig programmeren, het wordt wel genoemd maar omdat de persoon die zelf de uitleg moet geven ook maar wat doet is er helaas niet veel meer dan de uitleg wat een buffer overflow is en een voorbeeld hoe dat voorkomen kan worden.

Wat nodig is is een ICT wereld waarin men net zo als bijvoorbeeld binnen de architectuur de advocatuur en andere oudere vakken jaren lang zich zelf zal moeten bewijzen om echt te kunnen groeien tot een hogere positie waar men dan ook weer jaren bezig is voor men op een hogere positie kan komen. Daar naast zal men natuurlijk er voor moeten zorgen dat alles wat op geleverd wordt zo wel automatisch als handmatig op gaten lekken en andere problemen wordt getest.
Innovatie en ontwikkeling gaan dan heel erg veel langzamer maar eindelijk is het mogelijk om er redelijk zeker van te zijn dat het geen men op levert wel echt veilig is. Helaas zijn er nog steeds in de cowboy tijd wat dat betreft, iedereen met een toetsenbord een een grote bek is al snel een web developer en dat levert dit soort dingen op simpel weg omdat de meeste web developers simpel weg de moeite niet nemen om te leren hoe het beter zou kunnen.

Hier heb je een goed punt merk het vooral op school dat leraren zelf soms ook geen benul hebben waar het over gaat.

Zou het dan niet beter wezen om de professionals die jij beschrijft te stimuleren om misschien leraar te worden? Ik snap dat er vele mensen zijn die dit niet zien zitten maar ik denk dat je op het onderwijs toch wel echte professionals mag verwachten en niet leraren die er bijna niks vanaf weten.

Ik ondervond zelf dat leraars onvoldoende hun vak kennen en onvoldoende de mogelijkheid hebben hun kennis te verbeteren noch te standaardiseren (en die dan ook correct toe te passen).

Om het onderwijs te verbeteren moet er naar mijn mening alleen les gegeven worden van diegene die de lessen samenstelt (onder assumptie dat die mensen er wel iets aan hebben en dat ze openstaan voor commentaar), ik denk dan videos oefeningen en het delen van informatie (ipv leraars die hun informatie verzinnen of zelfs aan leerlingen vragen te doen als huiswerk).

En professionele mensen (langdurig) in het onderwijs zie ik persoonlijk niet zitten (tenzij ze dat zelf zien zitten) want die hebben recht op hun carriere, hoeveel het ook mag helpen. Maar dat is puur mijn mening.

Zou het dan niet beter wezen om de professionals die jij beschrijft te stimuleren om misschien leraar te worden? Ik snap dat er vele mensen zijn die dit niet zien zitten maar ik denk dat je op het onderwijs toch wel echte professionals mag verwachten en niet leraren die er bijna niks vanaf weten.

Dat zou wel beter zijn, Maar voor niets gaat de zon op. Het grootste probleem ligt echter in het feit web ontwikkeling een nieuwe sub tak is net zoals er vele anderen sub takken zijn ontstaan. Het fundamentele probleem ligt in het feit dat deze nieuwe sub takken sneller ontwikkelen als dat de scholen er een juiste structuur voor kunnen maken. En dat deze takken waarschijnlijk al weer overbodig zijn op het moment dat de scholen eindelijk een beetje niveau heeft behaald. Ik denk dat er iets fundamenteel mis is bij de manier waarop scholen deze nieuwe technologieën aan de man proberen te brengen.

Je ziet dat in alle nieuwe vakken (En dat zij er momenteel veel). Vooral de autodidacten de mogelijkheid hebben om niveau te verkrijgen van het nieuwe vak wat zij willen beheersen. Maar Autodidacten halen hun kennis en ontwikkeling toch ergens vandaan? En dat is precies wat de scholen fout doen. Ik denk dat de enige manier voor scholen om deze snelheid bij te benen is om goed te onderzoeken hoe sommige individuen wel kunnen wat zij niet kunnen. En dat is dat deze individuen (Zogenaamde) autodidacten. Heftig steunen op nieuwe technologieën. Zonder deze technologieën zou de school immers geen probleem hebben net als vroeger aangezien zij de snelheid van de groei van een technologie in handen hadden.

Scholen proberen om technologie te gebruiken om technologische ontwikkelingen bij te benen maar je ziet dat dit vaak gedaan word door de oude garde. 1000 computers in een hal neerzetten. dure software pakketten aanschaffen. en wat kunnen ze nog meer doen. En dat is het fundamentele probleem. Ze kunnen niet veel meer doen. Onderwijs is gemeenschappelijk geworden. We zijn in een tijd beland waarin 1 man (op dit moment) meer dan 95 miljoen lessen heeft geleverd over de hele wereld. http://www.khanacademy.org/

En om een lang verhaal nog langer te maken , Iedereen heeft zijn lot tegenwoordig in zijn eigen handen. Aangezien de school het er niet meer voor je in kan leggen. Wat de scholen wel kunnen doen en zullen moeten doen is veel meer prioriteit stellen in het ondersteunen van de abstracte ontwikkeling. elke Nederlandse ict'er zou abstracte wiskunde en logica moeten krijgen, de waarde moeten leren van informatie. (Ik bedoel een sql injectie voorkomen is zeer specifiek) en in een paar minuten geleerd. Als een ict'er de waarde snapt van de informatie achter zijn systeem zal die eerder de benodigde technieken leren om dit te garanderen.

De meeste ict'ers die op dit moment worden opgeleid weten nog helemaal niet wat ze later gaan doen. Je kan iemand leren wat wij nu als innovatief ervaren. Alleen dit is juist wat we de laatste decennia verkeerd deden. De web programmeur van nu moet word misschien wel de kinect body motion interface programmeur van morgen. Zonder deze abstracte ontwikkeling gaan krijgen we de volgende decennia weer hetzelfde probleem maar dan erger (Veel erger).

[Reactie gewijzigd door Anoniem: 109989 op 7 januari 2012 01:17]

jaren lang zich zelf zal moeten bewijzen om echt te kunnen groeien tot een hogere positie

Haha. Maar in de praktijk is het anders, de goede programmeurs blijven programmeren (want die vinden dat leuk en halen er voldoening uit), de mindere programmeurs worden manager, projectleider of zoiets, wat verder van de details.

Als ik naar mijn directie loop en ze vertel dat we even als een gek wat geld moeten investeren om de website veilig te maken kijken ze me vreemd aan. Ik zal echt met super goede argumenten moeten komen willen ze het accepteren, verder zullen ze me pas gelijk geven wanneer dr iets fout gaat (ongeacht met hoeveel voorbeelden je komt.)

Nu zijn wij natuurlijk geen software bedrijf en ontwikkelen wij onze sites inhouse (hobby van de IT afdeling) waardoor wij kosteloos beveiliging updates kunnen doorvoeren. Maar ik kan me helaas goed voorstellen dat meerdere directies op deze manier werken/denken...

Noem ook de kosten erbij van de voorbeelden waarbij de beveiliging gebroken is, met een vergelijking hoeveel het kost wanneer het vooraf wordt opgelost.
Het laatste is altijd goedkoper omdat er hetzelfde werk gedaan moet worden als bij het eerste.
Echter komen er bij het eerste meer kosten bij kijken omdat je niet alleen de fout zelf op moet lossen maar ook de gevolgen. Daarnaast gaat er veel goodwill verloren en lopen enkele klanten hoogstwaarschijnlijk weg.

Daar heb je gelijk in maar het verschilt in de markt waarin je opereert. In de markt waarin wij zitten geldt dat totaal niet. Wij kunnen gewoon klant gegevens kwijtraken omdat wij geen belangrijke gegevens bewaren (betalingen worden ingelezen aan de hand van een uniek ID en niet bijv de bankrekening en mail adressen zijn algemeen). Ook kunnen wij bijv gewoon onze webshop afsluiten zonder dat de klanten daar problemen mee hebben. De B2B markt werkt gewoon iets anders dan de B2C markt (zo zie je bijv nooit echt veel nieuws over B2B werkzaamheden van de grote partijen en de kleinere partijen zie je nooit in het nieuws)

Ja, dat is jouw redenering. Je kan ook als volgt redeneren: Het is goedkoper om het achteraf op te lossen, omdat er per kwetsbaarheid hetzelfde werk gedaan moet worden maar je hoeft alleen de kwetsbaarheden op te lossen waar 'vanzelf' tegenaan gelopen wordt.

Ikzelf schrijf software for een redelijk groot bedrijf, en heb al meer dan eens moeten aantonen dat onze software niet veilig is (uiteraard alleen wat ikzelf niet heb geschreven).

We hebben zelf als team ook regels staan dat onze software via automatische test software getest wordt, uiteraard niet 100% veilig maar het wordt wel dagelijks getest.

We zijn nu ook bezig via peer reviews het team op een hoger nivo te krijgen kwa ontwikkeling. Je kunt dus best je eigen software meer veilig houden door jezelf te controleren en elkaar te controleren.

Mocht directie niet luisteren, dan ga je zelf een paar uurtjes een testcase maken om het aan te tonen

Dat maakt het bedrijf nog steeds verantwoordelijk voor het slechte beveiligingsniveau.

Let wel, het gaat niet om het beschermen van je eigen spullen, maar beschermen van andermans spullen (privacygevoelige gegevens) die aan jouw bedrijf ter goeder trouw in bewaring zijn gegeven.

Blijkbaar kunnen veel bedrijven die verantwoordelijkheid niet aan, als de directie blijkbaar een regelmatige security-check niet acceptabel vindt.

ontwikkelen wij onze sites inhouse (hobby van de IT afdeling) waardoor wij kosteloos beveiliging updates kunnen doorvoeren

Dat is niet kosteloos. Want die uren krijgen de it'ers gewoon doorbetaald en kunnen ze niet aan andere taken besteden.

mits je een team hebt wat zich strikt aan de werktijden houdt

Wij zijn een middel groot internationaal opererend bedrijf... Helaas neemt dat met zich mee dat de mensen met een internationale functie vaak lange dagen maakt. Die paar uurtjes extra om wat te verbeteren zijn dan ook niet erg

Je moet wat doen als je hogerop wilt komen

Dus ja, ik had het niet uitgelegd, maar dat is voor ons gewoon kosteloos

Nu zijn wij natuurlijk geen software bedrijf en ontwikkelen wij onze sites inhouse (hobby van de IT afdeling)

Dat is natuurlijk ook een feilloze garantie voor topkwaliteit onkraakbare websites. Ik laat m'n bedrijfsauto's ook onderhouden door de secretaresse omdat ze wel eens Top Gear kijkt, want ik wil natuurlijk niet onverwacht stil komen te staan.

precies, de een lacht om de fout van een ander maar vergeet dat zijn itérs de zelfde fout hebben gemaakt. 2 weken laten is die zelf de lul.

maak er gewoon een regel van dat je minimaal 1x per weer even all it nieuws leest o.a. die sql injecties. want dit is niet de 1e keer eerder de 100e keer dat dit gebeurd in 2 a 3 maanden

Hoe wil het nieuws lezen je redden van SQL-injectie? SQL-injectie is al zo oud als SQL zelf en elke software-ontwikkelaar die zich er niet tegen wapent begaat een professionele doodzonde. User input mag nooit maar dan ook echt nooit in een query terechtkomen en het feit dat dat hier toch kan is een blunder van jewelste. Niet omdat de developers het nieuws niet gelezen hebben, maar omdat ze zich niet bewapend hebben tegen de meest basale kwetsbaarheid die een systeem kan hebben.

Een manager, maar ook developers moet zich uiteraard wel realiseren wat de risico's zijn van een project.
Als je weet dat je zelf PHP en MySQL gebruikt, en tegelijkertijd veel leest van SQL injecties, dan moet je je als manager en developers realiseren dat je misschien wel vatbaar bent, zeker als je leest hoevaak dit gebeurt.

Dus ja, het nieuwslezer help zeker om risico's in te schatten en weten wat er gebeurt in je vakgebied.

dat bedoel ik jij snapt het tenminste.
als je het leest, kan je misschien denken van: "Oh ik zal onze eigen beveiliging maar eens na lopen".

Je eigen beveiliging moet je nalopen als dat zin heeft. Als je weet dat je developers secuur omgaan met hun testmethodes dan zul je hooguit eens in de zoveel tijd een pen-test hoeven (laten) doen om te zien of je vatbaar bent of niet.

En nogmaals, als je afhankelijk bent van de fouten van anderen om zelf geen fouten te hoeven maken, dan doe je ook als manager iets verkeerd.

Simpel, dat kost veel tijd die er misschien niet is, of vaak is het dus uitbestede opdracht waardoor je niet ff snel de boel kunt controleren.

We hadden de maximale wachtwoordlengte aangepast naar twaalf tekens om dit soort aanvallen te voorkomen

Pardon? Dit soort aanvallen voorkom je door te je variabelen te controleren en escapen, alvorens je ze in een query stopt...

Bovendien lijkt het me dat ze ook wel eens hun wachtwoorden mogen hashen. Als je met een sql injectie in het wachtwoordveld kan inloggen betekend dat ook de input van de gebruiker onveranderd met database vergeleken wordt. Als de boel eerst gehashed zou worden zou die hele sql injectie niet meer kunnen werken.

Ontdek een sql injectie die je toestaat om database data te tonen en met een beetje geluk kan je (na gebruik van een rainbow table) alsnog inloggen.

Zeker door een limiet op de wachtwoordlengte te leggen maak je dat wel heel erg makkelijk

MySQL heeft een functie om te hashen in de sql query zelf dacht ik.

MySQL heeft een functie om te hashen in de sql query zelf dacht ik.

Dat klopt, dan gebruik je de md5(...) of sha1(...) functies. Wat ze niet gebruiken, omdat deze hack dan tot een syntax error zou leiden - door de manier van commenten zou er dan een ongesloten haakje overblijven, en zelfs als dat geen probleem zou zijn zou de "or 1=1" dan tussen de haakjes staan en derhalve de filterconditie niet opentrekken.

De hack kan echt alleen werken als de query letterlijk 'WHERE Password = '$password' bevat, en ja de passwords staan dus inderdaad per definitie volledig onversleuteld in de database.

Als je wachtwoorden probeert te hashen in SQL, kan iemand, zoals al eerder vermeld, een log in MySQL aanzetten en zo het wachtwoorden achterhalen. Nou is dat niet direct een situatie waar je je denk ik wil tegen bewapenen aangezien de hoster alle toegang heeft tot je data+PHP. Dus als hij echt wil, dan kan hij alle wachtwoorden achterhalen (bijvoorbeeld door de hashfuncties van PHP om te schrijven zodat hij alle input ergens in een file dumpt). Maar het is wel zo dat sommige sites foutmeldingen laten zien, inclusief queries. Dan krijg je dus ook het wachtwoord te zien in alle proxies en caches die er tussen de client en server zitten.

En tenslotte is het nog eens zo dat MySQL alleen MD5 en SHA-1 hash-functies aanbiedt. Deze zijn beide niet erg veilig bevonden. SHA-2 zou eigenlijk op dit moment de enige hash-functie moeten zijn die je gebruikt. En als je dan toch bezig bent om je hashfuncties aan te passen, dan zou ik direct maar eens kijken naar HMAC en PBKDF2.

En tenslotte is het nog eens zo dat MySQL alleen MD5 en SHA-1 hash-functies aanbiedt. Deze zijn beide niet erg veilig bevonden. SHA-2 zou eigenlijk op dit moment de enige hash-functie moeten zijn die je gebruikt. En als je dan toch bezig bent om je hashfuncties aan te passen, dan zou ik direct maar eens kijken naar HMAC en PBKDF2.

Toch zijn ze veilig genoeg voor wachtwoorden, de wachtwoorden zijn alleen in 99 van de 100 gevallen veel te simpel. En dan is het met een rainbow table vrij eenvoudig om de juiste hash na te maken... Het maakt dan ook niet uit welke hashing methode wordt gebruikt, de input is gewoon te simpel.

Wat onveilig is... In een shared hosting omgeving kan de hoster query log aanzetten en staat er alsnog het plain text wachtwoord in de query (naast mogelijk sniffen tussen app. & database). Gewoon altijd hashen in de prog. taal en niet in de DB, wel zo veilig.

Dat zijn dus dingen die JIJ bv wel weet, maar veel andere developers niet.
Hetzelfde is bv met .NET, ik kom regelmatig goed doorgewinterde .NET developers tegen die geen idee hebben dat je hun code zo kunt terughalen met een programma als reflector en zo wat aanpassingen kunt maken en opnieuw kunt compileren als je daar niet specifiek iets tegen doet (wat dus niet standaard in Visual Studio zit)..

Het fatsoenlijk voorkomen van SQL-injecties is basiskennis op het gebied van o.a. MySQL-databases. Dat niet iedereen dit weet is geen punt, maar als je webbeheerder bent bij een bedrijf zou dit niet mogen gebeuren.

Je zou het kunnen vergelijken met een Nederlands-docent die niet weet dat de verleden tijd van 'ik loop', 'ik liep' is. Dat een willekeurige Nederlander dit fout doet is (discussieerbaar) te begrijpen, maar als je besluit Nederlands te geven mag je toch wel kunnen verwachten dat je beter weet dan basisschool Nederlands.

[Reactie gewijzigd door ThePendulum op 6 januari 2012 00:22]

Is dat wel een echt probleem? De hoster heeft toch al toegang tot alle sources en de hele database, die bevindt zich immers op zijn machine.

Variabelen uit een script plukken is toch al wat moeilijker dan elk commando dat naar mysql gaat loggen.

Als de hoster onbesproken in jou gegevens gaat neuzen en het wordt bekend, is de kans erg groot dat het hele bedrijf de deuren kan sluiten. Om deze reden doen de meeste hosting providers ook niet aan dit soort praktijken.

Binnen een uur na de melding werd de kwetsbaarheid opgelost.

Ze hebben de maximale wachtwoordlengte aangepast naar 9

Beter nog is het stored procedures te gebruiken. Controleren en escapen is ook niet echt handig.

Kan je dat toelichten of een link geven die dat beschrijft (uit interesse vraag ik dit)?

Je weet dat stored procedures niet per definitie immuun zijn voor SQL injection?

Dat kunnen ze wel zijn wanneer ze de *enige* manier zijn om bij de data te komen.

Wanneer je dus je SP's definiëert met een gebruiker die bij de nodige data kan, maar de user die gebruik maakt van de SP's heeft zelf geen directe toegang tot de tabellen dan is het meeste wat je kunt doen garbage input aan de SP's meegeven. Wanneer die slim genoeg zijn om dat te valideren is er dus niets aan de hand.

Dan is het kernpunt dus het valideren, niet de stored procedure, toch ?

Zoals thedude0 Hierboven noemd is een prepared statement veiliger.. ook stored procedures zijn vatbaar voor SQL injecties

Gewoon een prepared statement gebruiken. Belachelijk dat dit soort lekken überhaupt mogelijk zijn bij een zichzelf serieus nemende website.

Ja, precies.

Welke idioot verzint het om dan maar de wachtwoord lengte aan te passen?

Inderdaad... quick fix is escapen, en daarna dieper onderzoeken hoe dat het zo kan mislopen...

Ik snap überhaupt niet waarom het wachtwoord niet allang gehasht was voordat het in de query geplakt werd. Iets zegt mij dat ze de wachtwoorden in plain tekst opslaan in de database

....

"We hadden de maximale wachtwoordlengte aangepast naar twaalf tekens om dit soort aanvallen te voorkomen"

....
....juist ja...dat is ook echt wel DE manier om SQL injection te voorkomen, [/sarcasme]
Maar ik begrijp gewoon niet hoe webmaster NOG STEEDS gewoon GEEN gebruik maken van mysql_real_escape_string(), ik bedoel het is één commando en je website is beveiligd tegen SQL Injection, en niet aankomen met "Ja maar de website is al 5 of 10 jaar oud" nee, bull, als jij leest hoeveel sites er tegenwoordig geSQLIed worden (ik heb dat woord net bedacht ja) en je weet dat jou site ook kwetstbaar is EN je weet dat mysql_real_escape_string() dit voorkomt..HOE kan je dat dan na-laten? IK snap het gewoon niet...is er iemand die mij dit uit kan leggen?

P.S. Sorry voor de rant en de ietwat negatieve ondertoon, het is natuurlijk wel lekker dat er direct wat aan gedaan wordt nadat het gemeld wordt, maar toch...

edit: was geen sarcastische ondertoon, maar een negatieve

[Reactie gewijzigd door BryanD op 5 januari 2012 16:51]

Juist het gebruik van mysql_real_escape_string() is gevaarlijk, omdat je moet onthouden om het te gebruiken en de kans dus groot is dat je het net die ene keer vergeet. Er zijn betere, systematischere oplossing zoals prepared statements of andere oplossingen.

[Reactie gewijzigd door compufreak88 op 5 januari 2012 16:56]

geheel mee eens,

die vogels van MySQL hadden helemaal niet een dergelijk functie moeten maken en alles direct via prepared statements moeten doen (dat bestond toen al). In die jaren (en nu nog steeds) staat het web vol van foute mysql+php voorbeelden. En alle beginnende PHP/MySQL 'programmeur' vallen gegarandeerd direct in die valkuil.

Er zou gewoon helemaal geen beginnende PHP/MySQL programmeur verantwoordelijk mogen zijn voor een klantendatabase van een multinational met 40.000 records, daar hebben de vogels van MySQL niet veel schuld aan...

geheel mee eens,

die vogels van MySQL hadden helemaal niet een dergelijk functie moeten maken en alles direct via prepared statements moeten doen (dat bestond toen al). In die jaren (en nu nog steeds) staat het web vol van foute mysql+php voorbeelden. En alle beginnende PHP/MySQL 'programmeur' vallen gegarandeerd direct in die valkuil.

Dit is toch meer een gevolg van de manier waarop PHP is ontwikkeld en de MySQL connector van PHP. Lijkt me dat die 'vogels' van MySQL daar weinig schuld aan hebben.

Heel PHP en zijn backwards-compatibiliteit is een zooitje net als het gros van de PHP programmeurs...

Gewoon je GET/POST variablen toewijzen aan lokale variabelen met filter_input en daarin alleen toestaan wat je verwacht. Daarna alleen die laatste variabelen gebruiken en prepared statements gebruiken voor connectie met de database. Als je dat als standaard practice aanhoudt, dan kan er weinig mis gaan mbt sql injectie.

offtopic:
...en ook gewoon OO programmeren, dan moet je iig al de gebruikersnaam goed hebben Kost je in sommige gevallen misschien een extra query, maar dat is niet zo heel erg.

Juist het gebruik van mysql_real_escape_string() is gevaarlijk

Onzin natuurlijk. Ik snap wel wat je bedoelt, maar je trekt hiermee een nogal rare conclusie. Er is niets ongevaarlijks aan mysql_real_escape_string en kan prima gebruikt worden binnen een framework. Wat je eigenlijk bedoelt te zeggen is dat elke keer met de hand een query opbouwen gevaarlijk is, omdat je weleens zou kunnen vergeten te escapen. Een waarheid als een koe.

Ja daar heb je dus ook wel gelijk in, het is echter wel zo dat dit mysql_real_escape_string één van de snelste en simpelste oplossingen is om binnen 5 minuten toe te passen, en dan nog: Als je leest dat er zoveel gehackt word, waarom niet je eigen website door de test heen halen?

Precies wat ik ook al dacht, met wat simpele handelingen kan je een website best goed beveiligen. Zeker als je gevoelige informatie bewaard, is beveiliging cruciaal. Kan mij voorstellen dan een applicatie niet 100% beschermd kan zijn tegen kwetsbaarheden, maar je moet zeker een poging wagen of tenminste je best doen.

Ze hebben de wachtwoorden dus ook nog eens als clear tekst in de database staan aangezien ze input niet eerst hashen.

Goed opgemerkt. Een maximale lengte impliceert vaak dat een site de wachtwoorden onversleuteld opslaat.

maxlength="12" staat er ook echt in die input... die coder heeft er dus helemaal niets van begrepen.

Dus als ik nu ff de POST/GET aanpas kan ik nog steeds binnen geraken?

Wauw, dat is wel heel amateuristisch inderdaad...

dat hoeft niet te betekenen dat er server side geen check op lengte 12 zit...

Vraag ik me toch wel af op welke manier ze nu die lengte hebben ingevoerd. Als het gedaan word met een javascriptje wat je invoer stopt op 10 tekens kun je die omzeilen door Javascript uit te zetten of met iets als FireBug de waarde te zetten op wat je wil doen.
*edit*
ffsnel gekeken, het is de maxlength html attribute op de input tag.

[Reactie gewijzigd door Meganutter op 5 januari 2012 17:24]

Tja, op het moment dat een developer dit soort designkeuzes gaat maken kun je er donder opzeggen dat hij over de rest ook wel niet goed zal hebben nagedacht. Het is dus niet zo heel vreemd als de maximale lengte dan vevolgens ook puur en alleen aan de clientkant bestaat.

Overigens, het feit dat dat attribuut bestaat wil nog niet zeggen dat het niet aan de serverkant geënforceerd wordt. Want juist als een dergelijke limiet zou bestaan dan wil je dat ook zo snel mogelijk duidelijk maken, dus pas je dat ook aan de clientkant toe.

Ik had een keer gezeik met een systeem waar dat dus niet zo was. Ik gebruikte een gegenereerd wachtwoord van 16 tekens, maar dat werd intern afgekapt op 12 tekens. Ik kon dus ook niet meer inloggen, want het inputveld accepteerde doodleuk 16 tekens en dat was ongelijk aan mijn 12-teken-wachtwoord dat opgeslagen stond op de server. Het heeft even geduurd voor ik daar achter was, en dan ben ik iemand die op de hoede is voor dat soort fouten. Een normale consument zou zoiets nooit ontdekken (maar die zou dan ook weer geen wachtwoord gebruiken van 13+ tekens )

[Reactie gewijzigd door .oisyn op 5 januari 2012 23:22]

Ach, ik ben absoluut geen ITer en weet niks van programmeren, lees Tweakers vooral voor nieuwtjes betreffende smartphones en het password van m'n email is ook langer dan 13 tekens. Iedereen die de krant leest/het nieuws kijkt ziet dat er heel vaak dingen worden gehackt waarbij wachtwoorden worden buitgemaakt, ook als je de details niet snapt kan je nog wel begrijpen dat je in ieder geval een sterk wachtwoord kan nemen, het kan sowieso geen kwaad en kan misschien helpen.

Het is denk ik meer zo dat het de meeste mensen niet interesseert omdat het geen groot probleem voor ze is als ze worden gehackt, met uitzondering van als er ook bank/creditcardgegevens worden buitgemaakt, maar dan zijn wachtwoorden weer niet boeiend. Behalve dan bij Paypal, maar de meeste gebruikers daarvan nemen denk ik geen simpel wachtwoord.

"We hadden de maximale wachtwoordlengte aangepast naar twaalf tekens om dit soort aanvallen te voorkomen", zegt George Jans, de webmaster van Kluwer Software.

Dit toont wel aan dat het nu wel eens tijd wordt om wat meer aandacht te schenken aan beveiliging. Want dit is natuurlijk wel een erg knullige 'oplossing', het toont aan dat de webmaster eigenlijk niet weet wat hij met beveiliging aanmoet. Dat zou standaard wel zo moeten zijn bij beheerders van databases met persoonsgegevens. Ik wacht nog steeds op een wetsvoorstel dat wat doet tegen zulke gebrekkige beveiliging hiervan.

[Reactie gewijzigd door bwerg op 5 januari 2012 16:47]

Ik ben bang dat de overheid hier niet veel kan doen. Als klant vertrouw je je gegevens toe aan het bedrijf, en je gaat er vanuit dat het bedrijf in kwestie jou gegevens beschermd. Ik zie het persoonlijk niet als een taak van de overheid om te bepalen of een bedrijf gegevens mag afnemen van gebruikers, het is ten slotte je eigen verantwoordelijkheid die je in handen van het bedrijf geeft met de voorkennis dat jij er vanaf dat punt geen controle meer over hebt.
In dit geval zou de overheid ook zover kunnen gaan dat je geen geheimpjes meer mag vertellen, omdat de kans bestaat dat het doorverteld wordt.

Een bedrijf dat zich moeite doet voor beveiliging kan/zou bewust een hacker loslaten op het systeem vóórdat het belangrijke informatie bevat. Deze hacker kan jou precies vertellen of hij makkelijk bepaalde functies kan omzeilen en hoe, voordat een kwaadwillige hacker dit voor je doet terwijl het systeem al in gebruik is genomen.
Het zou mooi zijn als er een organisatie is die een aantal goede hackers in dienst heeft, en certificaten uitdeelt voor website die goedgekeurd zijn zodat de klant weet waar hij aan toe is. Waarschijnlijk bestaat zo een organisatie wel, maar ik ben op dit uur wat te lui om het te Googlen, hehe.

[Reactie gewijzigd door ThePendulum op 6 januari 2012 00:34]

Je kunt dit al aanpakken door civielrechtelijke actie te ondernemen, de wet geeft je al ruimte om nalatigheid aan te pakken.

In plaats van de wachtwoord lengte te beperken (wat is dat voor een onzin) en daarmee te beveiligen zou je ook gewoon normaal je input kunnen escapen zoals het hoort.

"We hadden de maximale wachtwoordlengte aangepast naar twaalf tekens om dit soort aanvallen te voorkomen"

Sorry, maar dan heeft de beste man weinig verstand van dit soort zaken. Het kleiner maken van het wachtwoordveld heeft echt niets uit te staan met al dan niet vatbaar zijn voor sql-injectie natuurlijk. Zoals het artikel al stelt zorgt het alleen maar voor zwakkere wachtwoorden.

Echt een heel erg basale fout, maar ja eigenlijk zijn alle sql-injectie fouten dat eigenlijk. Vrijwel elk framework heeft wel kant-en-klare methoden om dergelijke aanvallen compleet onmogelijk te maken.

Zogauw je ergens rond de 1 á 3 tekens overhoud mag je wel stellen dat het injection-proof is, maar dan maak je het een hacker erg makkelijk om in te loggen gezien er slechts ~50.000 mogelijkheden zijn. Als er 40.000 klanten in het systeem staan, heb je dus vrijwel meteen raak. Met veel pech moet je 5 keer proberen.

Het incorrect beveiligen van het systeem is één, maar als je de fout ontdekt en hem dan zo onzinnig oplost is je blijkbaar geslaagde sollicitatie een applaus waard.