Hackers kraken database MySQL.com

Reacties

« 1 2 3 »

Door hAl, maandag 28 maart 2011 10:50

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 hAl op maandag 28 maart 2011 10:51]

Door BlackHawkDesign, maandag 28 maart 2011 10:58

Ze staan inderdaad in hun hemd, maar liever dit dan een groot lek in de beveiliging van hun database software

Door T-men, maandag 28 maart 2011 13:21

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.

Door arjankoole, maandag 28 maart 2011 13:25

alleen slecht beveiligde database van MySQL.com.

slechte code op mysql.com, de beveiliging van de database is niet direct iets mis mee.

Door deadeyes, maandag 28 maart 2011 13:42

ja ... en vaak worden die websites dan nog gemaakt en onderhouden door externe firmas.
Dus als die het slecht schrijven ...

Door Yezpahr, maandag 28 maart 2011 13:45

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 maandag 28 maart 2011 15:32]

Door GeeMoney, maandag 28 maart 2011 14:06

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 maandag 28 maart 2011 14:07]

Door vampke, maandag 28 maart 2011 15:01

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

Door jon.kiji, maandag 28 maart 2011 16:46

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.

Door OpenMinded, maandag 28 maart 2011 16:54

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.

Door kozue, dinsdag 29 maart 2011 11:43

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...

Door lfs, maandag 28 maart 2011 11:01

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.

Door gassiepaart, maandag 28 maart 2011 11:07

zelfs dan kan je het achterhalen, mist de salt bekent raakt..

Door Pimmetje16, maandag 28 maart 2011 11:24

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 maandag 28 maart 2011 11:24]

Door Janoz, maandag 28 maart 2011 11:52

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.

Door geez, maandag 28 maart 2011 12:31

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.

Door firest0rm, maandag 28 maart 2011 12:49

Door Remmes_NT, maandag 28 maart 2011 13:07

deze mensen weten gewoon veel van het onderwerp af

Door MaZeS, maandag 28 maart 2011 13:12

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 maandag 28 maart 2011 13:14]

Door Rizon, maandag 28 maart 2011 13:27

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.

Door DrPoncho, maandag 28 maart 2011 13:35

Door jon.kiji, maandag 28 maart 2011 16:51

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.

Door firest0rm, maandag 28 maart 2011 23:47

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 maandag 28 maart 2011 23:48]

Door SWINX, dinsdag 29 maart 2011 00:29

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"

Door timobruins, dinsdag 29 maart 2011 11:51

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?

Door deadeyes, maandag 28 maart 2011 13:44

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.

Door ajakkes, maandag 28 maart 2011 17:00

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.

Door willemWS, maandag 28 maart 2011 11:21

" 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.

Door NMe, maandag 28 maart 2011 12:18

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.

Door Janoz, maandag 28 maart 2011 11:49

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.

Door jon.kiji, maandag 28 maart 2011 16:53

Hashes ook

Door awulms, maandag 28 maart 2011 20:55

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.

Door curry684, maandag 28 maart 2011 12:12

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...

Door Marijn_S, maandag 28 maart 2011 13:49

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

Door Janoz, maandag 28 maart 2011 16:07

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.

Door mcDavid, maandag 28 maart 2011 10:51

Hmm dat is wel een pijnlijke onthulling! Al zegt het natuurlijk weinig over de kwaliteit van MySQL, maar over de kwaliteit van de scripts die de website gebruikt. Desondanks zit natuurlijk niemand op ditsoort nieuws te wachten, en een website over een database al helemaal niet.

Door et36s, maandag 28 maart 2011 10:52

Opvallend is dat een hoge manager bij MySQL, Robin Schumacher, een wachtwoord van slechts vier cijfers had.

Dit geeft toch weer te denken

Door sbmuc, maandag 28 maart 2011 10:56

Dit gebeurt jammergenoeg nog steeds veel te vaak. Maar beetje beheerder had echter een fatsoenlijke password policy aangemaakt.

Door silentsnake, maandag 28 maart 2011 11:23

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.

Door YopY, maandag 28 maart 2011 12:08

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.

Door Floor, maandag 28 maart 2011 12:44

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.

Door AtlonXP1800, maandag 28 maart 2011 10:57

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.

Door Elmo_nl, maandag 28 maart 2011 11:00

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.

Door Fastman, maandag 28 maart 2011 11:46

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.

Door F!SH, maandag 28 maart 2011 12:05

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

Door Jeroen, maandag 28 maart 2011 12:26

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.

Door Limaad, maandag 28 maart 2011 12:51

waar is optie 3? gewoon goeie passwords gebruiken?

Door musiman, maandag 28 maart 2011 13:08

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.

Door jon.kiji, maandag 28 maart 2011 16:56

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 maandag 28 maart 2011 16:57]

Door , maandag 28 maart 2011 14:34

Door TiG, maandag 28 maart 2011 14:37

Of 3306?

Door ivog, dinsdag 29 maart 2011 10:53

1337, misschien ?

Door plempkat, maandag 28 maart 2011 13:38

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.

Door Dooxed, maandag 28 maart 2011 10:52

Dit gaat om de db van de website mysql.com zelf, dus ik neem aan dat er alleen indirect risico voor de code van het project bestaat. Snel toegang afsluiten en iedereen wachtwoord laten veranderen, zou ik zeggen. En je eigen website na lopen op noob-achtige sql-fouten

Door WouZz, maandag 28 maart 2011 10:56

Hoe erg zou Oracle dit vinden?

Door bomberboy, maandag 28 maart 2011 10:59

Heel erg, aangezien MySQL is overgenomen door Oracle (overname Sun enz.)

Door WouZz, maandag 28 maart 2011 11:04

Ja, en waar komt het geld vandaan?

Door jon.kiji, maandag 28 maart 2011 16:59

Erm... Bij Oracle, wat is je punt?

Gezien het feit dat MySQL tegenwoordig van Oracle is, is dit natuurlijk ook vrij directe imagoschade aan het adres van Oracle.

Door WouZz, maandag 28 maart 2011 18:13

Volgens mij is de MySQL database nog steeds niet complementair aan de Oracle database, ze bedienen slechts verschillende markten. En volgens mij is dit bericht eerder imagoschade voor de naam MySQL dan voor Oracle. Een beetje fear en distrust zal ze niet heel slecht uitkomen. Ik geef toe dat het misschien vergezocht is, en vanuit een redelijk perspectief vrij krankzinnig, maar Oracle heeft op dat gebied wél een dubieuze naam.

Door Imprezzion, maandag 28 maart 2011 10:56

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.

Door Dingen, maandag 28 maart 2011 11:21

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.

Door multimediacar, maandag 28 maart 2011 11:37

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 maandag 28 maart 2011 13:51]

Door mstam, maandag 28 maart 2011 11:56

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 maandag 28 maart 2011 12:02]

Door YopY, maandag 28 maart 2011 12:11

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.

Door Ford Prefect, maandag 28 maart 2011 12:55

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.

Door fdh, maandag 28 maart 2011 12:57

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.

Door AtlonXP1800, maandag 28 maart 2011 11:57

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.

Door multimediacar, maandag 28 maart 2011 13:53

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.

Door jon.kiji, maandag 28 maart 2011 17:05

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.

Door RobertMe, maandag 28 maart 2011 10:57

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.

Door Tukkertje-RaH, maandag 28 maart 2011 11:24

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.

Door ToySoldier1992, maandag 28 maart 2011 11:47

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?

)

Door ScorpionX, maandag 28 maart 2011 12:20

gewoon lachen

Door arjankoole, maandag 28 maart 2011 13:29

Wie gaat als medewerker van zo'n school dat nu ook letterlijk invoeren?

Is dat een rethorische vraag? Genoeg.

Door Iva_Bigone, maandag 28 maart 2011 10:57

De onderdelen van het alom geprezen LAMP gaan een beetje LIMP

L van Linux: nieuws: Microsoft bevestigt hack van Linux-systemen in bedrijfsnetwerk
A van Apache: nieuws: Hackers bemachtigen wachtwoorden Apache Foundation
M van MySQL: nieuws: Hackers kraken database MySQL.com
P van PHP: nieuws: Aanvallers kraken accounts op PHP-wikiserver

[Reactie gewijzigd door Iva_Bigone op maandag 28 maart 2011 11:01]

Door _JGC_, maandag 28 maart 2011 11:05

Mja, die L is gewoon knulligheid van Microsoft: een testopstelling in een testlab wat gehackt is. Daar kan linux zelf niet veel aan doen.
De rest is gewoon knulligheid van de projecten zelf. Uiteraard zegt het niks over de software zelf, maar als je de infrastructuur van zo'n project niet kunt vertrouwen, dan komt automatisch de vraag of er ook met de software zelf gerommeld is door derden.

Door Xantios, maandag 28 maart 2011 11:09

Vind dit een beetje vreemde conclusie sinds de helft van de bronnen die je noemt op de websites zelf zitten, en niet in de software....

daarbij zijn woensdag 14 april 2010 en donderdag 14 oktober 2010 al een flinke tijd achter ons... verwacht dus dat dit allang opgelost is.

Door IIsnickerII, maandag 28 maart 2011 11:02

blij dat dit bekend is. dan kunnen ze ten minste het lek fixen.

Door Xantios, maandag 28 maart 2011 11:09

Zo kun je het ook bekijken, aan de andere kant.... beetje blunder dat het er überhaupt in zit / zat.

Door beta990, maandag 28 maart 2011 11:04

PDO -> prepare() functie, anyone?

« 1 2 3 »

Op dit item kan niet meer gereageerd worden.

11:08	Tv-divisie Philips verwacht kwartaalverlies tot 120 miljoen euro - update
10:26	Bedenker packet switching is overleden

Nieuws I/O

Shortcuts

Categorieën

Lees meer over

Gerelateerde content

Gerelateerde jobs

Reacties

13:01 Nieuws

22:34 Productreviews

23:01 Vraag & Aanbod

25-05 Jobs

20:30 Etc.

23:04 Reacties

23:11 Forum

25-05 Gesponsorde acties

00:16 Tweakblogs

26-05 Computable headlines

25-05 CRN headlines