LinkBack URL
About LinkBacks
In hoeverre is MySQL vatbaar voor SQL-injection?
Alles wat ik er tot nu toe over gelezen heb gaat over SQL server. De methoden die daar gebruikt worden (bijvoorbeeld: foefelen met GROUP BY en HAVING) hebben geen vat op MySQL.
Ik vermoed dat er wel andere manieren zullen zijn?
gewoon quotes en addslashes gebruiken...
gebruik mysql_real_escape en dan is da allemaal opgost
Da's eigenlijk een vrij domme vraag, een RDBMS laat in principe nl. om het even welke query toe (de mate van succes hangt daarbij uiteraard af van het feit of de syntax van je query wel kloptOorspronkelijk geplaatst door Gitan
). De vraag die je wellicht wil stellen is : hoe voorkom ik SQL injection met <voeg hier je favoriete web scripting taal in>?
SQL injection heeft nl. op zich niks te maken met het gebruikte RDBMS, maar wel alles met de manier waarop je script/programma parameters doorgeeft naar dat RDBMS toe.
en wat is de beste manier om dit te voorkomen?
De eerste stap is de controle van de input uiteraard, ipv die zomaar klakkeloos door te sturen naar je queries.
bij systemen met beperkte beveiliging is die makkelijk te gebruiken. Met addslashes kunde zorgen dat het niet vraagt naar wachtwoord. Maar je moet wel een gebruikersnaam hebben
Mijn wenkbrauw gaat spontaan omhoog.bij systemen met beperkte beveiliging is die makkelijk te gebruiken. Met addslashes kunde zorgen dat het niet vraagt naar wachtwoord. Maar je moet wel een gebruikersnaam hebben
Gebruikt de andere wenkbrauw.
Mijn mond valt open :o
Als je php met mysql gebruikt dan kan de schade nog beperkt blijven want de mysql_query instructie kan maar 1 query afhandelen.
Zoals hier boven reeds gezegd, zeker de userinput goed afhandelen.
Anders kan je eens de Programmers hacking guide raadplegen omtrent mysql injection.
Mar natuurlijk hangt alles af van het gebruikte RDBMS
ksnap toch ook niet waar dit op slaat ze, als ge de input deftig afhandeld (en da's geen complex iets) dan kan er geen bal gebeuren...
ik geloof dat dJeez hier ooit iets over gepost heeft in de sticky
vreemd, 1 van de belangrijkste ivm php & mysql injection is nog niet gezegd:
NOOIT in de end-user versie je mysql-errors weergeven. Op die manier kan de hacker stilletjes aan, door te blijven proberen een succesvolle hack uitvoeren omdat hij altijd informatie over zijn failure krijgt.
Daarnaast: u niet laten wijsmaken dat injects zoals "; DROP bla bla bla" mogelijk zijn, de queries van php ondersteunen geen multiple statements. Wat Smoerf dus ook al zei.
En wilt maatje zijn grootste veiligheidsleak ooit eens uitleggen :/?
eigenlijk in een end-user version: nooit enige vorm van system output geven, als je het dan toch wil doen, zelf opvangen en iets obscuurs als "database error, please send an email to ... and describe what you were trying to do" ofzo
general error, db error, "user" errorma ni iets van "sql says: fubar query dude!"
Yup.eigenlijk in een end-user version: nooit enige vorm van system output geven, als je het dan toch wil doen, zelf opvangen en iets obscuurs als "database error, please send an email to ... and describe what you were trying to do" ofzo
general error, db error, "user" error
Beste is zelfs dat je php fouten opvangt tot op bepaald niveau en er eigen versie van geeft. Voor de rest kan je dan een db aanleggen of idd met mail sturen. Je kan idd de gebruiker nog om extra info vragen, maar zelfs zonder dat zou elke fout onmiddellijk moeten gemeld worden. Uw systeem moet foolproof zijn
Moest je nu in php programmeren raad ik je ten sterkste MDB2 aan..
het bespaart je hele hoop tijd, en er word aan security gedacht!
http://pear.php.net/package/MDB2
prepared statements?
Probleem bij PHP is dat 't een run-once-forget taal is. Je gaat dus geen prepared statements in memory kunnen bijhouden afaik.
Ik heb gitan dan ook niets horen zeggen over php.
Maar je hebt uiteraard wel gelijk.
php doet wel degelijk aan basis caching e.d. (hoewel het nog veel beter kan). Toch sins zend2
Op dit moment bekijken 1 gebruikers deze discussie. (0 leden en 1 gasten)
Regels voor berichten
Met citaat reageren