Centraal MySQL query variables escapen.

[Keiichi]

Tijdens een kleine review van een stuk code door mij gemaakt is het escapen van variablen in MySQL queries ter sprake gekomen. Momenteel wordt in mijn code op elke moment dat een query gevormd word variablen ge-escaped.

Degeen die de code gereviewed heeft had het er over dat dit beter op een centraal punt kan gebeuren, echter zonder technisch uitleg of iets dergelijks (accountants )

Ik heb er over zitten te denken hoe ik 'centraal' query variablen moet escapen. Maar ik kan met niets zinnigs komen waarbij ik escape calls weghaal en 1 weg zet voor waar de query uiteindelijk word uitgevoerd. (Er is bv wel een centrale functie om MySQL errors op te vangen)

Kan iemand hier wat meer over uitleggen?

[user109731]

Misschien bedoelt hij dat je de query maakt met daarin placeholders voor de in te vullen waarden. Vervolgens geef je de query en de variabelen mee aan een functie die netjes alle waarden vervangt door de (escaped) variabelen en de query uitvoert...

[TeeDee]

Wat heeft een accountant met jouw code te maken? Ik denk dat je een consultant de schuld wil geven?

[Macros]

Moet je je queries niet gewoon parametriseren? Dan worden de variabelen automatisch door de driver geëscaped. Ik neem aan dat je php gebruikt?

[Keiichi]

de code is in perl geschreven

Ik heb een database module geschreven welke het voor me zelf wat makkelijker te maken. Verder te noemen $db

$db heeft een subroutine die een query als string neemt en deze naar de DBI:mysql driver stuurt.. Hier gebeurd ook alle standaard check (is de database handle actief, fouten opvangen e.d.)

Elke keer wanneer ik een query ergens maak, maak ik deze als volgt:

$query = sprintf("SELECT * FROM `table` WHERE `text_fld` = %s AND `int_fld` = %d", $db->quote_string($txt), $int);

quote_string is de escape functie, deze doet niet meer dan het invoken van 'quote' op de database handle.

Dit alles leek mij een goede manier, zeker mbt mysql injections. Het tegenargument was, dat je dit maar 1x hoeft te vergeten om een injection flaw te hebben. Mijn argument was dat je gewoon goed moest programeren, maar dat was niet goed genoeg.

Het is echt een accountant welke deze review gedaan heeft (Het was geen audit, het was alleen gezien tijdens een kleine 'show' van de broncode van een applicatie)

[TeeDee]

Als je toch een DB module hebt, waarom dan niet daar de escape logica plaatsen?

[Verwijderd]

Keiichi schreef op vrijdag 28 maart 2008 @ 09:41:
[...]

Dit alles leek mij een goede manier, zeker mbt mysql injections. Het tegenargument was, dat je dit maar 1x hoeft te vergeten om een injection flaw te hebben. Mijn argument was dat je gewoon goed moest programeren, maar dat was niet goed genoeg.

Dat is vreemd. Ik kan namelijk geen situatie verzinnen waarin een fout in een programma geen gevolgen heeft voor de veiligheid ervan.

Als ik jou was, zou ik de accountant om opheldering vragen. Als hij geen oplossing heeft, lult hij maar wat in de ruimte. Heeft hij wel een oplossing, laat het hier dan weten, we zijn zeer benieuwd!

[Janoz]

Je wilt het misschien niet horen, maar imho heeft de accountant wel gelijk. Misschien is het een idee om eens naar geparameteriseerde queries te kijken. Geen idee of dit beschikbaar is in perl, maar in veel andere talen heb je dit wel. Verder is dit niet heel lastig zelf te implementeren wanneer je al een database module hebt.

[Keiichi]

Ik kan er verder mee nu.

Een voorbeeldje die ik gezien heb is:

$sth = $dbh->prepare("SELECT email, userid FROM members WHERE email = ?;");
$sth->execute($email);

Dit zou de truc moeten klaren.

Janoz schreef op vrijdag 28 maart 2008 @ 09:49:
Je wilt het misschien niet horen, maar imho heeft de accountant wel gelijk. Misschien is het een idee om eens naar geparameteriseerde queries te kijken.

Ik heb nooit gezegd dat de accountant geen gelijk had. Als ik dacht dat ie zeker te weten ongelijk was, dan had ik nooit de vraag hier gesteld

[ Voor 50% gewijzigd door Keiichi op 28-03-2008 10:03 ]