Cookies op Tweakers

Tweakers maakt gebruik van cookies, onder andere om de website te analyseren, het gebruiksgemak te vergroten en advertenties te tonen. Door gebruik te maken van deze website, of door op 'Ga verder' te klikken, geef je toestemming voor het gebruik van cookies. Wil je meer informatie over cookies en hoe ze worden gebruikt, bekijk dan ons cookiebeleid.

Meer informatie

Door , , 116 reacties

Hackers zijn erin geslaagd om via een gat in de beveiliging van de MySQL-website een dump van de database te maken door gebruik te maken van sql-injectie. De MySQL-databasesoftware wordt door veel websites gebruikt.

Dumps van de database van MySQL.com verschenen op de Full Disclosure-mailinglijst en op Pastebin, waarbij onder meer de structuur van de database zichtbaar was, evenals namen, wachtwoordhashes en e-mailadressen van gebruikers. Van sommige gebruikers was ook het daadwerkelijke wachtwoord zichtbaar, dat waarschijnlijk dankzij gebruik van rainbow tables werd achterhaald. Opvallend is dat een hoge manager bij MySQL, Robin Schumacher, een wachtwoord van slechts vier cijfers had.

De hackers ontfutselden de informatie met behulp van sql-injectie, waarbij aan database-requests eigen sql-code wordt toegevoegd door bepaalde parameters te manipuleren. Daardoor kan informatie worden opgevraagd of gewijzigd. Sql-injectie is te voorkomen door bepaalde karakters te strippen uit variabelen die door gebruikers worden ingevuld, bijvoorbeeld de inhoud van formulieren. MySQL heeft daarvoor een speciale functie, die het op zijn eigen website mogelijk niet overal gebruikte.

Het is onduidelijk tot welke databases de hackers toegang hadden, maar de mogelijkheid om een dump van een aanzienlijk deel van de database te maken, wijst erop dat de misbruikte mysql-query op redelijk hoog niveau met de database communiceerde. Zondag werd bekend dat ook de website van Sun vatbaar was voor sql-injectie. Daarbij kon een minder groot deel van de database worden opgevraagd, maar er waren wel onder meer e-mailadressen zichtbaar.

MYSQL.com dump

Moderatie-faq Wijzig weergave

Reacties (116)

Erg domme fout natuurlijk door de webdevvers daar bij MySQL. Elke PHP ontwikkelaar die boven het "scriptkiddie" niveau uit komt moet toch wel bekend zijn met het fenomeen SQL Injection.

Wel toevallig dat gisteren de site van Sun ook al lek bleek te zijn. Lijkt mij dan dat dezelfde groep achter beide hacks zit.
Sql-injectie is te voorkomen door bepaalde karakters te strippen
Te strippen? Wat nu als iemand een naam heeft waar een ' in staat? Dan zou dat karakter weg vallen (net zoals nu in deze post). Er zal zoals daarna staat een functie gebruikt moeten worden die de "illegale" karakters escaped (een \ ervoor zet waardoor ze niet geïnterpreteerd worden als speciaal karakter). Of, nog beter, gebruik maken van prepared statements. Waarbij in de query placeholders/variabelen komen te staan waardoor de query zelf helemaal veilig is, en je daarna maar hoeft aan te geven "deze variabele krijgt die inhoud" waarna je dan de query kunt draaien. De "mysql" functies van PHP kunnen dat niet, maar de nieuwere, "mysqli" functies kunnen dat wel. Daarvoor is o.a. mysqli_prepare. En ook PDO, die ook een MySQL driver heeft bevat verschillende functies om te werken met prepared statements.
Te strippen? Wat nu als iemand een naam heeft waar een ' in staat?

Hehe.... XKCD.com heeft daar een fraai voorbeeld van, 'exploits of a Mom':

http://xkcd.com/327/

Maar inderdaad - en dat gebeurt op meer plekken - niet alle tekens zijn altijd te gebruiken in een invoerveld, onder meer vanwege veiligheid.
Off-topic: Maar die strip is gewoon dom: Wie gaat als medewerker van zo'n school dat nu ook letterlijk invoeren? :')


(of moeten we zo ver niet over een strip nadenken en gewoon lachen? :D)
Wie gaat als medewerker van zo'n school dat nu ook letterlijk invoeren?
Is dat een rethorische vraag? Genoeg.
Misschien een leuke addon voor de openings post
Het is onduidelijk tot welke databases de hackers toegang hadden, maar de mogelijkheid om een dump van een aanzienlijk deel van de database te maken, wijst erop dat de misbruikte mysql-query op redelijk hoog niveau met de database communiceerde. Zondag werd bekend dat ook de website van Sun vatbaar was voor sql-injectie. Daarbij kon een minder groot deel van de database worden opgevraagd, maar er waren wel onder meer e-mailadressen zichtbaar.
Je hebt maar één klein gaatje nodig om je hele database structuur open te leggen (voor de huidige mysqluser)

Met tools als SQLMap ( http://sqlmap.sourceforge.net ) kun je zien hoe een gemiddelde attacker jouw exploit zou aanvallen. Dat is zo simpel als: voer hem de query string, wat parameters, en sqlmap begint byte voor byte je hele databaseschema uit te lezen. echt *friggin'* scary.

Ik raad iedereen aan die nog niet een compleet beeld heeft van wat een sql injectie nou eigenlijk inhoudt, of die denkt dat je daar echt überhacker voor moet zijn die sqlmap site te bekijken en dit soort testen op z'n eigen meuk uit te voeren.
Opvallend is dat een hoge manager bij MySQL, Robin Schumacher, een wachtwoord van slechts vier cijfers had.
Dit geeft toch weer te denken :S
Dit gebeurt jammergenoeg nog steeds veel te vaak. Maar beetje beheerder had echter een fatsoenlijke password policy aangemaakt.
En als de hoge manager maar hard genoeg schreeuwt dat ie een kort password wilt krijgt hij dat wel hoor. Zo gaat dat bij (grotere) bedrijven. Heeft dikwijls weinig te maken met de beheerder.
Als beheerder zijnde zorg je er dan wel voor dat een eenvoudig wachtwoord simpelweg niet mogelijk is in de software, dat die geweigerd wordt. En als ontwikkelaar maak je de software gewoon zo.
Een beheerder is geen security officer en visa versa.
Een security officer bepaalt de procedures, controleert deze en stuurt beheerders en management aan inzake veiligheid. Security is namelijk veel meer dan alleen wat rechten instellen.

Een goede security officer is iemand met beslissingsbevoegdheid, communicatief vaardig, stevig in de schoenen, kennis van zaken en te overdonderen.

Ik ken een zeer goede security officer die dit bij hele grote bedrijven doet. Directie maakt bezwaar? Uitleggen waarom dat niet mag en wat de consequenties zijn. Directeur nog steeds bezwaar? Laat maar tekenen dat hij de volledige verantwoordelijkheid draagt, laten tekenen wat de consequenties kunnen zijn enz. Een goede manager/directeur begrijpt de boodschap en zal 'schikken'.

OT: Dit is reputatieschade eerste klas.
Dat niet alleen, kennelijk heeft men geen salt gebruikt bij het opslaan van de wachtwoorden. Overigens heeft dit niets met de kwaliteit van de mysql database te maken, maar met de kwaliteit van hun website.
Als ik het goed begrijp, zijn de wachtwoorden gekraakt met behulp van een rainbow table. Het kan volgens mij dus net zo goed een collision zijn op de hash van het wachtwoord van die hoge manager. Dat wil dus niet per definitie zeggen dat zijn wachtwoord ook daadwerkelijk vier cijfers was.
3333? :+

Maar on-topic: Tja, het is redelijk gênant om als MYSQL zijnde je eigen database gehackt te krijgen terwijl de fix voor deze feature bekend is.
Ook vraag ik mij af of het een 'echte' database betreft of een honey-pot want ik kan me echt niet voorstellen dat een MYSQL manager een 4-cijferig wachtwoord heeft en daarmee blijkbaar zoveel informatie kan opvragen. Maar zoals altijd: bij de loodgieter thuis lekt het ook wel eens dus niets nieuws onder de zon. Wel ben ik benieuwd wat MYSQL nu gaat doen, netjes al zijn klanten informeren, het lek dichten of...? We gaan het meemaken.
Ach ja, wat is veilig?

- een wachtwoord van 20 karakters die je op elke website gebruikt
- een wachtwoord van 4 karakters die op elke website anders is

Persoonlijk zeg ik het tweede, zolang je account na 3x foutief inloggen geblokkeerd wordt. Bij het eerste moet je wachtwoord maar in één onversleutelde database zitten en men kan op al je accounts inloggen.

Wachtwoorden zijn gewoon stom en het OS zou gewoon iets moeten aanbieden dat met een afzonderlijke hardware werkt met pincode. Zoals een kaartlezer voor je bankkaart. En dan op basis daarvan en wachtwoordbeheer.
En als die hardware gekraakt wordt zit je dus in je eigen situatie nummer 1...

Ik stel me de vraag of je wel weet wat je zegt. Het securityrisk potentieel in jou scenario is nog groter dan plaintext paswoorden :x
Hoe het ook zij, als je een zwak wachtwoord gebruikt om iets belangrijks te vergrendelen dan doen al die andere sites/rekeningen/accounts er niet toe.
waar is optie 3? gewoon goeie passwords gebruiken?
Een goed wachtwoord dat middels rainbowtables te kraken is, is nog steeds niet goed... Wat Fastman op een wat knullige manier probeert te zeggen is echter dat een extra vorm van authenticiatie NAAST je wachtwoord aan te bevelen is. In die zin heeft Fastman dan ook gelijk.

Something you know (=password) plus something you have (=securitytoken)

Het gebruik van wachtwoorden als enig authenticatiemiddel is m.i. gewoon achterhaald. Kijk anders even naar de uitzending van Kassa! afgelopen weekend waar duidelijk naar voren gebracht werd dat Paypal, door het koppelen van jouw bankrekening en/of creditcard, de veiligheid omlaag brengt. Via Paypal kun je zonder de Rabobank Randomreader of ING TAN codes etc. geld overmaken!!!!! Je hebt alleen de inloggegevens naam en wachtwoord nodig.
Het beste is in loggen met 'iets dat je hebt' en 'iets dat je weet'.
Oftewel inloggen met een hardware token en een wachtwoord.
Beiden hebben ze hun zwaktes en sterktes.

edit: Of ik doe gewoon het betoog van musiman nog dunnetjes over...

[Reactie gewijzigd door jon.kiji op 28 maart 2011 16:57]

1337, misschien ?
Een beetje een afgang om juist door SQL injectie vanuit de website naar de database gepakt te worden terwijl SQL aanroepen van vanuit websites juist de core business is van mySQL.

[Reactie gewijzigd door 80466 op 28 maart 2011 10:51]

Het is ook niet meer van deze tijd om nog steeds sql injecties op je website te hebben. Het gebruik van prepared statements maakt het risico hierop vrijwel nihil. En wie slaat nu zijn wachtwoorden op als hash? Gebruik dan in ieder geval een salt + 1000 keer het gehashte wachtwoord.
Waarom 1000 keer? Het is basisschoolwiskunde om te bewijzen dat een hash onveiliger wordt naarmate je hem vaker toepast omdat je per definitie de keyspace verkleint met iedere slag...
Dat is helemaal niet onveiliger. Het heet key stretching en is een heel normaal principe in cryptografie, bijv als onderdeel van PBKDF2. Ik hoop tenminste dat RSA de basisschoolwiskunde wel onder de knie heeft ;)
Het is daadwerkelijk redelijk simpel om te bewijzen dat meerdere keren hashen de keyspace verkleint. Hashen is immers injectief. Hoeveel is echter lastiger. De afweging is hoe die verkleinde keyspace refereert met de toegenomen uitrekencomplexiteit.

Het wiki artikel is dan ook een beetje ruk. Ze wijzen wel op het voordeel (16bit 'langere sleutel' bij 64000 itteraties), maar vergeten het nadeel van de verkleinde keyspace te noemen. Zolang die minder is dan 16 bits is keystretching inderdaad sterker.
zelfs dan kan je het achterhalen, mist de salt bekent raakt..
Maar dan is het gebruik van een kant en klare rainbow table niet mogelijk zover ik weet.

Correct me if i am wrong ;)

En dat zorgt er weer voor dat het veel meer tijd kost om eventele wachtwoorden te ontfrutselen.

[Reactie gewijzigd door Pimmetje16 op 28 maart 2011 11:24]

Als de salt bekend is kun je keurig een rainbowtable maken. De crux zit hem er voornamelijk in dat je je salt variabel hebt (elke user zijn eigen salt). Dan zul je voor elke gebruiker een eigen rainbow table moeten maken, en dat is precies hetzelfde als gewoon gaan lopen bruteforcen.
Ja lol, met eenzelfde salt voor elke user is er ook niet veel aan.
Ga dan gewoon maar cleartext wachtwoorden gebruiken:p

Wat is de extra moeilijkheid van een verschillende salt? Er is geen extra moeilijkheid.
Die is er wel degelijk. Als de gebruiker het wachtwoord password gebruikt en je hashed deze dan kan je er vergif op innemen dat deze in een rainbow table staat.
Als je deze salt door er password_meteenmooiesalt van te maken dan kan iemand die de hele database van wachtwoorden heeft en de salt weet een rainbow table gaan maken van veel gebruikte wachtwoorden met de salt.
Als je echter een salt en pepper gebruikt door er password_meteenmooiesalt_gebruikerscode van maakt kan de hacker voor ieder wachtwoord een nieuwe rainbowtable gaan maken. Dat is nogal veel werk.

Als de gebruiker op iedere site hetzelfde wachtwoord gebruikt zijn na 5 minuten niet al zijn accounts gekraakt.
Als je het echt netjes doet, gebruik je zowel salt als pepper. Ofwel zowel een hardcoded salt, als een per-user pepper (hoewel ik mensen heb gezien die de terminologie omdraaien). De laatste kan bijvoorbeeld de gebruikersnaam van de gebruiker zijn of een ander unieke variabele van de gebruiker.
Nerds? Een veilige site kunnen maken maakt je een Nerd?
Als je niet weet wat rainbow tables zijn of salts of zelfs SQL injection, begin dan maar niet aan het bouwen van een website met enige dynamiek.

Misschien is dit niet de juiste site voor je. :P
ben ik ook niet van plan

maar blijft tog een feit dat het nerds zijn

zit vaak genoeg op tweakers en heb veel interesse in de reacties
maar soms is het een beetje teveel van het klef gedoe

@DrPoncho
en het was grappig bedoeld eh
dat je er boos om word is niet mijn probleem

[Reactie gewijzigd door firest0rm op 28 maart 2011 23:48]

dit is nou eenmaal een meer tech-onderwerp?
het lijkt me juist een waardevolle aanvulling van @geez, die aangeeft hoe je je beveiliging kan regelen.

en het is natuurlijk "toch" en "wordt"
Ik zie de clue niet waarom jij vindt dat mensen, die dit doen Nerds zijn!?
Dus als ik veel van Games afweet ben ik Geweldig, en kan ik een website bouwen ben ik dus een Nerd,

leuker is, een mensen kan maar 1/2 dingen hebben waar hij/zei heel goed in is,
de eene is goed in dit, en de ander in dat,

En als jij denkt dat ik een Nerd ben om ik ook website's bouw, denk dan zelf ook
even, stel jij zou website's maken, ben je dan ook zelf een Nerd?

En als je zoiets neerzet bij zo'n nieuwsbericht, heb ik gevoel dat jij eerder een nerd bent.
waarom lees je dit eigelijk?
Je moet wel eens wat leren als je een opleiding volgt..
Bij een hogere informatica opleiding worden je dit soort dingen als het goed is geleerd...
Hashes opslaan zonder salt vind ik nogal slecht. Pepper is inderdaad nog beter.

[Reactie gewijzigd door MaZeS op 28 maart 2011 13:14]

deze mensen weten gewoon veel van het onderwerp af
Wees blij dat er nog enkele tweakers zijn. En tbh zijn die zaken basiskennis. Zelfs als je geen ervaring hebt met websites maken, moet je zo'n dingen op voorhand weten.
" Gebruik dan in ieder geval een salt + 1000 keer het gehashte wachtwoord. "

Wees eens eerlijk, hoeveel projectjes lopen er hier in Nederland waarbij jij dit ook niet hebt gedaan.
Ik zal het iets minder subtiel zeggen: het hashen van een hash (zonder bij elke hash een eigen salt te gebruiken) is per definitie minder veilig omdat de verzameling tussenhashes kleiner is vanwege hun vaste aantal bits. ;)
Het is ook niet meer van deze tijd om nog steeds sql injecties op je website te hebben.
Niet meer? Nooit geweest!

Daarnaast bestonden prepared statements al in de vorige eeuw.
In mysql bestonden prepared statements niet in de vorige eeuw. Daar bestaan ze pas sinds release 4.1, die ergens rond 2005 ofzo is uitgekomen. Maar evengoed, dat betekent dus dat mysql toch inmiddels zo'n 6 jaar de tijd heeft gehad om hun website te herschrijven om overal bind variabelen te gebruiken. Een stuk veiliger en een stuk performanter. Slordig dus dat zoiets nu nog misgaat.
Ze staan inderdaad in hun hemd, maar liever dit dan een groot lek in de beveiliging van hun database software :)
De software MySQL is dus niet lek, alleen slecht beveiligde database van MySQL.com.

Ja, dan sta je idd in je hemd, maar gelukkig valt de schade voor een gewone gebruiker van MySQL in principe wel mee. Ik zou zeggen: leer ervan en laat het jou niet overkomen.
alleen slecht beveiligde database van MySQL.com.
slechte code op mysql.com, de beveiliging van de database is niet direct iets mis mee.
Met de beveiliging was kennelijk wel wat mis.
Onder beveiliging word verstaan dat alle gaten dichtgegooid worden en de boel dus beveiligd is.

Uit het artikel:
Sql-injectie is te voorkomen door bepaalde karakters te strippen uit variabelen die door gebruikers worden ingevuld, bijvoorbeeld de inhoud van formulieren. MySQL heeft daarvoor een speciale functie, die het op zijn eigen website mogelijk niet overal gebruikte.
Het schort dus wèl aan de beveiliging, want de beveiliging is niet overal toegepast. Of dat nou aan de database zijn beveiliging ligt, die van de website, of die van de servers, firewalls, routers, etcetera, dat maakt allemaal niet uit.

Er zit in de software al een functie die dit soort geëikel moet tegengaan, maar als de mensen het niet willen toepassen op elke pagina, ja dan is het tòch een probleem bij de beveiliging :), ook al is er niets mis met de software.

@2 hieronder, mijn comment was een comment op arjankoole...
Hij suggereerde dat er niets mis was met de beveiliging van de DATABASE.
Maar de beveiliging van de database is in dit geval niet in orde. En toegevoegde woorden zoals waar het probleem dan precies ligt is overbodig, dat probeerde ik even uit te leggen, maar kennelijk werden mijn woorden verkeerd opgevat.

[Reactie gewijzigd door Yezpahr op 28 maart 2011 15:32]

Ik denk dat er meer bedoeld wordt dat het dus geen "bug" of "lek" is in de software maar dat het verkeerde gebruik ervan heeft gezorgd dat dit dus te achterhalen viel.
Dit betekent namelijk dat niet direct alle bedrijven die dit MySQL product gebruiken vatbaar hoeven zijn.

Stel dat dit in de basis software zat, dan had iedereen als een gek moeten gaan patchen, daar doelen ze denk ik op.

[Reactie gewijzigd door GeeMoney op 28 maart 2011 14:07]

Het schort dus wèl aan de beveiliging, want de beveiliging is niet overal toegepast. Of dat nou aan de database zijn beveiliging ligt, die van de website, of die van de servers, firewalls, routers, etcetera, dat maakt allemaal niet uit.
tuurlijk maakt dat wel uit: een lek bij het bedrijf achter mysql door een menselijks programmeerfout is mijn probleem niet, een lek in de mysql software is daarentegen een heel groot probleem
Beveiliging van de database, dus beveiliging op databaseniveau.
Daar hebben firewalls, website, servers, enz, enz. niet veel mee te maken, dat is ook meer beveiliging van de infrastructuur.
ja ... en vaak worden die websites dan nog gemaakt en onderhouden door externe firmas.
Dus als die het slecht schrijven ...
inderdaad, dit is gewoon een probleem dat iedere web applicatie kan raken (en ook gewone applicaties).
Een beetje knullig wel dat ze hun eigen website niet goed beveiligd hebben.
Er is lijkt me ook geen relatie met de Sun website, beide sites hadden net zo goed op MSSQL of Oracle kunnen draaien, dan waren er dezelfde problemen geweest.
Noem me paranoïde als je wilt, maar het zou me niks verbazen als dit een truc van Oracle is om de naam van MySQL te verbinden met slechte associaties. Het is wel opmerkelijk dat het nu pas gebeurt, en nooit in de jaren dat het zelfstandig of van Sun was. Oracle wil helemaal niet dat jij een gratis open source db gebruikt. Die willen dat jij betaald voor hun dure proprietary meuk...
Jongens ligt dit nou aan de beveiliging van de website "mysql.com" of aan de beveiliging van de serversoftware? Dat lees ik nergens namelijk.
In principe ligt de kwetsbaarheid voor SQL injection altijd bij de website, of de communicatie náár de databaseserver. Althans dat zijn de plaatsen waar je het kunt voorkomen. Het liefst doe je dat als ontwikkelaar op beide plaatsen (invoer validatie én prepared statements) :) Je kunt zoals al eerder gezegd de database zelf niet beveiligen tegen SQL injection omdat deze het verschil helemaal niet kan zien. Het is dus géén kwetsbaarheid in MySQL.

[Reactie gewijzigd door Cloud op 28 maart 2011 11:34]

Wat dacht je van de database user die de website applicatie gebruikt om in te loggen op de database alleen de voor de website bestemde stored procedures toe te laten gebruiken en andere toegang tot de database niet?
Nee het ligt aan het gebrekkig programmeren van de website, als ergens een query word gebruikt als:

Select * from News where id=12 en deze word niet goed gesaniteerd, dan kan iemand iets doen als:

Select * from News where id='' union select * from eenwillekeurige tabel

Uiteraard is bovenstaande wat simpel uitgelegd, maar zo iets zal gebeurd zijn.
Een SQL injection ligt bijna altijd aan de beveiliging van de server software. Die lieten toe dat gebruikersinput ongefilterd kon worden doorgegeven aan een sql query, die daarna de gegevens blootstelde.
Juist niet, dit ligt absoluut niet aan de database server, die doet gewoon zijn werk.
Het is de website zelf die niet veilig genoeg is (of bedoel je met 'server software' de website zelf, beetje slechte woordkeuze aangezien zowel de website als de database op een server draaien :-) In dit geval is de website echter de client en de database de server).
Dus dan ligt het probleem bij de web applicatie server. Ook dat is server software...
Waarom zou de database server de web server blind moeten vertrouwen? Waarom zou je de beveiliging mogelijkheden van de database server niet gebruiken i.p.v. dat de website applicatie op de database inlogt met admin rechten?
Aan de beveiliging van de website.
Hmm ja ik vind het allemaal best ironisch, MySQL die gehacked wordt dmv. SQL injecties...

Had op z'n minst verwacht dat ze hun eigen website hier goed tegen beveiligd hadden.
De database zelf kan er niet tegen beveiligd zijn. De applicatie die gebruik maakt van de database moet zorgen dat er geen SQL geïnjecteerd kan worden. Dat is in dit geval dus de website, daarvan was de beveiliging onder de maat.
Neen hoor, Oracle heeft producten waarbij SQL injection gemonitord wordt en desnoods geblokkeerd of veranderd ZONDER de applicaties te moeten aanpassen.

Het blijft vreemd waarom MySQL dit nog niet geimplementeerd heeft, misscien is die transitie nog in de maak...

@ mstam; De producten zijn oa Database Firewall en Advanced Security for DB

In kort komt het erop neer dat sql statements worden bekeken en indien het kwaadaardig is kan er niets worden doorgegeven of wordt de statement aangepast.
Het heeft ook intelligentie aan boord waardoor niet alleen whitelisting en blacklisting gebruikt wordt.

[Reactie gewijzigd door multimediacar op 28 maart 2011 13:51]

Neen hoor, Oracle heeft producten waarbij SQL injection gemonitord wordt en desnoods geblokkeerd of veranderd ZONDER de applicaties te moeten aanpassen.
Hoe werkt dat?

Als de standaard query "WHERE Email = 'someemail' AND Password = 'somepassword' is, kan dit bijv. herschreven worden naar "WHERE Email = 'someemail' AND Password = 'somepassword' OR Email <> '' OR Password <> ''"

Hoe kan de database weten dat dit niet de juiste query is? Dat kan dus niet.

In PHP is het verstandig magic_quotes_gpc standaard uit te zetten en mysql_real_escape_string te gebruiken voor elke variabel die wordt weggeschreven naar de database. Ook variabelen van velden zoals booleans/radio buttons, want die kunnen makkelijk misbruikt worden aangezien een ontwikkelaar verwacht dat deze standaard de waarde 0 of 1 heeft en dus te lui kan zijn deze te escapen.

Gebruik zelf PHP's MCRYPT_RIJNDAEL_128 voor en/decryptie.

[Reactie gewijzigd door mstam op 28 maart 2011 12:02]

Het is verstandiger om dit helemaal buiten je applicatie te (laten) doen door gebruik te maken van prepared statements. Dat is zowel veiliger, performanter, en eenvoudiger in je code, ook omdat je dan (bijvoorbeeld) je SQL scripts als externe resources kunt gebruiken, ipv lelijke inline concats.
Oracle heeft Oracle Database Firewall: http://www.oracle.com/tec...ewall/overview/index.html ik denk dat dat is wat multimediacar bedoelt. Helaas had dat Oracle niet geholpen in deze want hun 'eigen' MySQL wordt niet ondersteund.
Je hebt een oracle database firewall:
http://www.oracle.com/tec...ewall/overview/index.html

Maar normaal moet je (ook voor performance) vrijwel altijd bind variabelen gebruiken, waarbij je geen sql injection kunt toepassen.

Daarnaast moet je geen sql statements gebruiken in je web code zelf.
Dit moet een afzonderlijke laag vormen (bv pl/sql) en bij je (web) applicatie roep je dan de procedures/functies aan die eventueel een record of een cursor teruggeven.
Hoe kan een database dat dan detecteren? De applicatie (waar de fout in zit) stuurt enkel een sql statement naar de database. Of daar een stuk sql injectie in zit lijkt mij vrij lastig te detecteren, want het zal vaak nog gewoon een valide sql statement zijn.
Dit is dus wel het geval voor Oracle, zie mijn toevoeging; elke sql statement wordt gekwalificeerd.

Dit heeft als grote voordeel dat je je applicaties niet hoeft aan te passen. En het heeft zeer weinig invloed op je performance.
Dit heeft als grote voordeel dat je je applicaties niet hoeft aan te passen.
Daar moet je niet op vertrouwen. Ik zit nu zelf in een database-migratietraject en dat zou dus inhouden dat het wisselen van database betrekking heeft op je mate van security. Dat wil je ook niet.
Kun je niet verschillende permissies instellen in de db en zo dit soort dingen aan de DB-kant enigszins beperken?

Meestal wordt er gebruikt gemaakt van één of ander superaccount waardoor er via SQL-injection leuk allemaal DROPs uitgevoerd kunnen worden...
Jups dat kan. Je kan bijvoorbeeld de DROP functies uitzetten voor de user is makkelijk. Alleen is het wel iets moeilijk om de SELECT uit te zetten voor de users tabel om zo'n dump te verkomen.
Wij gebruiken uitsluitend stored procedures en de websuser heeft allen rechten om de sprocs uit te voeren.

Dus select gaat ook altijd via een sproc.
Ik snap bepaalde dingen niet aan de salt kolom.

hashed_password = md5 of sha(password + unieke_salt_hash)

Hier kan ik nog inkomen. Maar ze hebben hier een dump gemaakt dus dan is toch ook de salt bekend. En als de salt bekend is kunnen ze gewoon rainbow techniek gebruiken want de unieke salt is gewoon bekend.
dat beantwoord mijn vraag dus :)

Als je de salt weet plus password hash dan is de salt niet heel heel nuttig dus.
blij dat dit bekend is. dan kunnen ze ten minste het lek fixen.
Zo kun je het ook bekijken, aan de andere kant.... beetje blunder dat het er überhaupt in zit / zat.
Lekker dan, om rechtstreeks vanaf mysql.com te kunnen downloaden moet je inloggen. Als hackers al passwords en domeinnamen (email) hebben en een argeloze developer die overal hetzelfde wachtwoord gebruikt wordt toegang krijgen tot databases van gebruikers een koud kunstje.
Nee hoor? Je kan altijd gewoon "No thanks, please send me directly to the download" of iets dergelijks kiezen.

Natuurlijk is dit wel erg slordig van Mysql zelf, maar iedereen maakt wel eens fouten. Maar zoals eerder gesteld ben ik wel benieuwd of dit inderdaad niet gewoon een honeypot was. Ik vind het toch een beetje onwaarschijnlijk dat de wachtwoorden slecht versleuteld zijn (sommige achterhaald met een rainbowtable) en dat een hoge pief een wachtwoord van 3 cijfers had.
Then again, a password is only as strong as the person who made it up dus wie weet is het echt zijn wachtwoord.

Op dit item kan niet meer gereageerd worden.



Apple iOS 10 Google Pixel Apple iPhone 7 Sony PlayStation VR AMD Radeon RX 480 4GB Battlefield 1 Google Android Nougat Watch Dogs 2

© 1998 - 2016 de Persgroep Online Services B.V. Tweakers vormt samen met o.a. Autotrack en Carsom.nl de Persgroep Online Services B.V. Hosting door True