Archief - MYSQL: vatbaarheid voor SQL-injection

Het archief is een bevroren moment uit een vorige versie van dit forum, met andere regels en andere bazen. Deze posts weerspiegelen op geen enkele manier onze huidige ideeën, waarden of wereldbeelden en zijn op sommige plaatsen gecensureerd wegens ontoelaatbaar. Veel zijn in een andere tijdsgeest gemaakt, al dan niet ironisch - zoals in het ironische subforum Off-Topic - en zouden op dit moment niet meer gepost (mogen) worden. Toch bieden we dit archief nog graag aan als informatiedatabank en naslagwerk. Lees er hier meer over of start een gesprek met anderen.
G

Gitan

Legacy Member
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?
f

flash_artist

Legacy Member
gebruik mysql_real_escape en dan is da allemaal opgost
d

dJeez

Legacy Member
Gitan zei:
In hoeverre is MySQL vatbaar voor SQL-injection?
Klik om te vergroten...
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 klopt :p). 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.
d

dJeez

Legacy Member
De eerste stap is de controle van de input uiteraard, ipv die zomaar klakkeloos door te sturen naar je queries.
m

maatje

Legacy Member
orez zei:
gewoon quotes en addslashes gebruiken...
Klik om te vergroten...
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 :p
W

WHiSPy

Legacy Member
maatje zei:
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 :p
Klik om te vergroten...

Mijn wenkbrauw gaat spontaan omhoog.
S

Smoerf

Legacy Member
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
L

Lashknife

Legacy Member
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...
D

DieselPower

Legacy Member
ik geloof dat dJeez hier ooit iets over gepost heeft in de sticky
k

killgore

Legacy Member
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 :/?
L

Lashknife

Legacy Member
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 ;) ma ni iets van "sql says: fubar query dude!"
k

killgore

Legacy Member
Lashknife zei:
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 ;) ma ni iets van "sql says: fubar query dude!"
Klik om te vergroten...
Yup.

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 :p.
W

WHiSPy

Legacy Member
VeNeReA zei:
prepared statements?
Klik om te vergroten...

Probleem bij PHP is dat 't een run-once-forget taal is. Je gaat dus geen prepared statements in memory kunnen bijhouden afaik.
V

VeNeReA

Legacy Member
Ik heb gitan dan ook niets horen zeggen over php.
Maar je hebt uiteraard wel gelijk. :)
k

killgore

Legacy Member
WHiSPy zei:
Probleem bij PHP is dat 't een run-once-forget taal is. Je gaat dus geen prepared statements in memory kunnen bijhouden afaik.
Klik om te vergroten...

php doet wel degelijk aan basis caching e.d. (hoewel het nog veel beter kan :(). Toch sins zend2
Het archief is een bevroren moment uit een vorige versie van dit forum, met andere regels en andere bazen. Deze posts weerspiegelen op geen enkele manier onze huidige ideeën, waarden of wereldbeelden en zijn op sommige plaatsen gecensureerd wegens ontoelaatbaar. Veel zijn in een andere tijdsgeest gemaakt, al dan niet ironisch - zoals in het ironische subforum Off-Topic - en zouden op dit moment niet meer gepost (mogen) worden. Toch bieden we dit archief nog graag aan als informatiedatabank en naslagwerk. Lees er hier meer over of start een gesprek met anderen.
Terug
Bovenaan