[PHP/MySQL] SQL injectie voorkomen

[Olaf van der Spek]

Ik kom helaas regelmatig PHP scripts tegen die kwetsbaar zijn voor SQL injecties. Code als:

PHP:

$a = $_GET['a'];
mysql_query("insert into T (A, B, C) values ('$a', '$b', '$c')");

Wat is de manier om dit te voorkomen?

Zelf dacht ik aan zoiets:

PHP:

mysql_query_safe("insert into T (A, B, C) values (?, ?, ?)", $a, $b,
$c);

De mysql_query_safe werkt een beetje zoals sprintf, met het verschil dat argumenten eerst door mysql_real_escape_string gehaald worden en daarna worden voorzien van quotes. Ints en andere veilige types worden direct verwerkt.

Volgens mij zit dit niet in PHP, zie ik iets over het hoofd?

http://bugs.php.net/bug.php?id=46202

Een PHP staff member raadt prepared statements aan, maar dat is toch heel iets anders.

[Juup]

Ik ben het hartgrondig met je eens.
Tijd dat de PHP designers hier iets aan doen.

[NMe]

Prepared statements doen toch precies wat jij wil?

PHP:

$stmt = mysqli_prepare($link, "INSERT INTO `T` (`A`, `B`, `C`) VALUES (?, ?, ?)");
mysqli_stmt_bind_param($stmt, 'sss', $a, $b, $c);

[Olaf van der Spek]

-NMe- schreef op dinsdag 30 september 2008 @ 15:42:
Prepared statements doen toch precies wat jij wil?

PHP:

$stmt = mysqli_prepare($link, "INSERT INTO `T` (`A`, `B`, `C`) VALUES (?, ?, ?)");
mysqli_stmt_bind_param($stmt, 'sss', $a, $b, $c);

Nee.
De syntax is al langer en complexer dan in mijn voorbeeld. In het ideale geval is de syntax niet of nauwelijks langer/complexer dan de onveilige versie.
Prepared statements zijn niet client-side, prepare doet een roundtrip naar de server, wat dus extra tijd kost. Ook is het nodig handmatig het parameter type te specificeren.
Bovendien is mysqli vereist. Ik weet niet of dat overal tegenwoordg al standaard is.

[Crayne]

Is het zoveel moeite om die functie zelf te schrijven of op te zoeken op het net? Dat wiel is al zo vaak opnieuw uitgevonden.

Een enkele functie in PHP zou mooi zijn, maar ik zie niet in waarom je er zo op gebrand zou moeten zijn.

[Olaf van der Spek]

Crayne schreef op dinsdag 30 september 2008 @ 16:12:
Is het zoveel moeite om die functie zelf te schrijven of op te zoeken op het net? Dat wiel is al zo vaak opnieuw uitgevonden.

Een enkele functie in PHP zou mooi zijn, maar ik zie niet in waarom je er zo op gebrand zou moeten zijn.

Ik kan hem zo 1 2 3 niet vinden. Als jij hem wel kan vinden, zou ik graag een linkje zien.

Waarom vind jij het raar dat ik zo gebrand ben op het voorkomen van kwetsbaarheden?
Ik vind het eigenlijk raar dat jij er zo makkelijk over doet.
Zeker aangezien SQL injecties redelijk vaak voorkomen.

[XWB]

/edit

Ik moet leren lezen

[ Voor 93% gewijzigd door XWB op 30-09-2008 16:16 ]

[NMe]

Olaf van der Spek schreef op dinsdag 30 september 2008 @ 16:14:
[...]

Ik kan hem zo 1 2 3 niet vinden. Als jij hem wel kan vinden, zou ik graag een linkje zien.

Waarom vind jij het raar dat ik zo gebrand ben op het voorkomen van kwetsbaarheden?
Ik vind het eigenlijk raar dat jij er zo makkelijk over doet.
Zeker aangezien SQL injecties redelijk vaak voorkomen.

Dat zegt hij helemaal niet. Hij (en ik ook) vindt het raar dat je zo gebrand bent op een kortere syntax. Als je dat zo graag wil, dan schrijf je een wrapperfunctie om deze constructie heen. Verder is je probleem van beveiliging gewoon opgelost met een prepared statement. Je zit nu te mekkeren over 2 extra regels code; alsof alles maar een standaardfunctie moet hebben in PHP.

[Olaf van der Spek]

-NMe- schreef op dinsdag 30 september 2008 @ 16:19:
Dat zegt hij helemaal niet. Hij (en ik ook) vindt het raar dat je zo gebrand bent op een kortere syntax. Als je dat zo graag wil, dan schrijf je een wrapperfunctie om deze constructie heen. Verder is je probleem van beveiliging gewoon opgelost met een prepared statement. Je zit nu te mekkeren over 2 extra regels code; alsof alles maar een standaardfunctie moet hebben in PHP.

Heb je over de rest van mijn bezwaren heengelezen?
En je weet zelf toch ook waarvoor de meeste developers kiezen als ze tussen een korte en lange variant kunnen kiezen?

[Crayne]

Olaf van der Spek schreef op dinsdag 30 september 2008 @ 16:14:
Ik kan hem zo 1 2 3 niet vinden. Als jij hem wel kan vinden, zou ik graag een linkje zien.

Zoeken is een kunst: php function prevent "sql injection"

Waarom vind jij het raar dat ik zo gebrand ben op het voorkomen van kwetsbaarheden?
Ik vind het eigenlijk raar dat jij er zo makkelijk over doet. Zeker aangezien SQL injecties redelijk vaak voorkomen.

En lezen is ook een kunst blijkbaar. Ik vind het niet raar dat je gebrand bent op het voorkomen van kwetsbaarheden, ik vind het raar dat je zo gebrand lijkt te zijn op de toevoeging van een native function aan PHP, terwijl het niet veel moeite is om zelf even na te denken en zelf een functie te schrijven die SQL Injection voorkomt.

Edit: goed, wat -NMe- dus zegt.

[XWB]

Wat is de manier om dit te voorkomen?

User input heel goed controleren.

Ik bouw altijd met sprintf een correcte string op.

PHP:

$a = mysql_escape_real_string ( $_GET['a'] );
$b = mysql_escape_real_string ( $_GET['b'] );
$c = mysql_escape_real_string ( $_GET['c'] );
$sql = sprintf ( 'INSERT INTO T (A, B, C) VALUES ("%s", "%s", "%s")', $a, $b, $c );

Als het integers moeten zijn, kan je het zo doen:

PHP:

$a = (int) $_GET['a'];
$b = (int) $_GET['b'];
$c = (int) $_GET['c'];
$sql = sprintf ( 'INSERT INTO T (A, B, C) VALUES ("%d", "%d", "%d")', $a, $b, $c );

Maar goed, dat schijnt die mysql_query_safe al te doen, maar eerlijk gezegd heb ik er liever zelf controle over. mysql_query_safe ken ik niet, en zou ik zelf ook niet gebruiken.

Een PHP staff member raadt prepared statements aan, maar dat is toch heel iets anders.

Het is een ander manier van werken, je zou eens naar PDO kunnen kijken.

[Crayne]

Hacku schreef op dinsdag 30 september 2008 @ 16:22:
[...]
Maar goed, dat schijnt die mysql_query_safe al te doen, maar eerlijk gezegd heb ik er liever zelf controle over. mysql_query_safe ken ik niet, en zou ik zelf ook niet gebruiken.

Die bestaat dus ook niet.

[.oisyn]

Ik zou alles gewoon naar een tekstbestand wegschrijven ipv een database, veel veiliger!

[XWB]

.oisyn schreef op dinsdag 30 september 2008 @ 16:26:
Ik zou alles gewoon naar een tekstbestand wegschrijven ipv een database, veel veiliger!

Zeg je dat nu om grappig te willen zijn, of omdat je een hekel hebt aan php?

[NMe]

Olaf van der Spek schreef op dinsdag 30 september 2008 @ 16:21:
[...]

Heb je over de rest van mijn bezwaren heengelezen?

Goed dan, ik ga er wel uitgebreider op in.

De syntax is al langer en complexer dan in mijn voorbeeld. In het ideale geval is de syntax niet of nauwelijks langer/complexer dan de onveilige versie.

Sorry, maar je zeurt. Het scheelt twee regels code, en of het al dan niet mooier is op deze manier is subjectief. Ik vind het een vrij nette oplossing.

Prepared statements zijn niet client-side, prepare doet een roundtrip naar de server, wat dus extra tijd kost.

A small price to pay. Jij noemt het een nadeel, ik noem het een voordeel; PHP hoeft in dit geval niet geupdate te worden als er wat verandert in de SQL-syntax.

Ook is het nodig handmatig het parameter type te specificeren.

Oei, stel je voor dat je daar als developer ook nog over na moet denken.

Bovendien is mysqli vereist. Ik weet niet of dat overal tegenwoordg al standaard is.

Het is de standaard voor PHP5. Een hoster die PHP5 biedt, biedt ook MySQLi.

En je weet zelf toch ook waarvoor de meeste developers kiezen als ze tussen een korte en lange variant kunnen kiezen?

De variant die het probleem oplost.

[Olaf van der Spek]

Crayne schreef op dinsdag 30 september 2008 @ 16:22:
Zoeken is een kunst: php function prevent "sql injection"

Geen van de resultaten op de eerste pagina laat een mysql_query_safe achtige oplossing zien.

En lezen is ook een kunst blijkbaar. Ik vind het niet raar dat je gebrand bent op het voorkomen van kwetsbaarheden, ik vind het raar dat je zo gebrand lijkt te zijn op de toevoeging van een native function aan PHP, terwijl het niet veel moeite is om zelf even na te denken en zelf een functie te schrijven die SQL Injection voorkomt.

Het is toch belachelijk dat bijna iedereen die MySQL functies op een veilige manier wil gebruiken eerst zelf een bepaalde functie moet schrijven?
Volgens mij is er onderhand wel aangetoond dat dat gewoon niet werkt, getuige de hoeveelheid kwetsbaarheden.

[Olaf van der Spek]

-NMe- schreef op dinsdag 30 september 2008 @ 16:33:
A small price to pay. Jij noemt het een nadeel, ik noem het een voordeel; PHP hoeft in dit geval niet geupdate te worden als er wat verandert in de SQL-syntax.

Is dat zo? Waar bewaar je de SQL queries dan? Volgens mij in de PHP code.

Oei, stel je voor dat je daar als developer ook nog over na moet denken.

Het is code duplicatie...

Het is de standaard voor PHP5. Een hoster die PHP5 biedt, biedt ook MySQLi.

Ah, mooi.

De variant die het probleem oplost.

Waarom wordt er in dat geval dan zoveel geschreven over SQL injectie?
In dat geval zou het namelijk een non-issue zijn, als iedereen de goede variant zou gebruiken.

[XWB]

Het is toch belachelijk dat bijna iedereen die MySQL functies op een veilige manier wil gebruiken eerst zelf een bepaalde functie moet schrijven?

Ja, beter nog, een database class. Ik heb er één gebaseerd op de mysql functies.

Waarom wordt er in dat geval dan zoveel geschreven over SQL injectie?
In dat geval zou het namelijk een non-issue zijn, als iedereen de goede variant zou gebruiken.

Omdat veel mensen het verkeerd doen. Jouw oplossing, die van -NMe- en mij zijn gewoon correct. Lange of korte syntax boeit totaal niet, zolang het maar correct en overzichtelijk is.

[ Voor 43% gewijzigd door XWB op 30-09-2008 16:38 ]

[NMe]

Olaf van der Spek schreef op dinsdag 30 september 2008 @ 16:33:
Het is toch belachelijk dat bijna iedereen die MySQL functies op een veilige manier wil gebruiken eerst zelf een bepaalde functie moet schrijven?
Volgens mij is er onderhand wel aangetoond dat dat gewoon niet werkt, getuige de hoeveelheid kwetsbaarheden.

Wat wil je nou? Je wil dat PHP een functie toevoegt die zoiets oplost, maar het moet wel exact in de syntax die jij zelf logisch vindt, want anders is het niet goed genoeg? Prepared statements kunnen nog meer dingen dan alleen inserts goed verwerken en daarom zijn ze wat complexer dan de syntax die jij voorstelt. Als je het simpeler wil hebben schrijf je een wrapperfunctie en anders kun je beter ophouden met zeuren.

[.oisyn]

Hacku schreef op dinsdag 30 september 2008 @ 16:27:
[...]


Zeg je dat nu om grappig te willen zijn, of omdat je een hekel hebt aan php?

Ik zie niet helemaal in wat een hekel aan PHP hebben te maken heeft met SQL injection eigenlijk...? Verder wens ik je vraag niet te beantwoorden (-NMe- sums it up quite well)

[ Voor 36% gewijzigd door .oisyn op 30-09-2008 16:37 ]

[XWB]

.oisyn schreef op dinsdag 30 september 2008 @ 16:36:
[...]

Ik zie niet helemaal in wat een hekel aan PHP hebben te maken heeft met SQL injection eigenlijk...? Verder wens ik je vraag niet te beantwoorden (-NMe- sums it up quite well)

Het zou fijn zijn als je gewoon niet gereageerd had.

Verder wens ik je vraag niet te beantwoorden (-NMe- sums it up quite well)

Hoeft niet, ik ken je mening wel.

[ Voor 15% gewijzigd door XWB op 30-09-2008 16:41 ]

[Crayne]

Olaf van der Spek schreef op dinsdag 30 september 2008 @ 16:33:
Geen van de resultaten op de eerste pagina laat een mysql_query_safe achtige oplossing zien.

Nee, de eerste link geeft je een kant-en-klare functie die je over de argumenten voor sprintf heen gooit en je hebt je mysql_query_safe.

Maar goed, je hebt je soapbox neergezet en ik geloof niet dat er iets is dat ik, of -NMe- of .oisyn of wie dan ook kan zeggen dat je er van gaat overtuigen dat je punt geen halszaak betreft.

[Olaf van der Spek]

-NMe- schreef op dinsdag 30 september 2008 @ 16:36:
[...]
Wat wil je nou? Je wil dat PHP een functie toevoegt die zoiets oplost, maar het moet wel exact in de syntax die jij zelf logisch vindt, want anders is het niet goed genoeg?

Ja, inderdaad.
Nee, de exacte syntax is natuurlijk niet zo belangrijk.

Prepared statements kunnen nog meer dingen dan alleen inserts goed verwerken en daarom zijn ze wat complexer dan de syntax die jij voorstelt. Als je het simpeler wil hebben schrijf je een wrapperfunctie en anders kun je beter ophouden met zeuren.

Mijn functie kan toch ook voor andere queries worden ingezet? En met een tweede functie die de query niet execute maar returned ben je nog flexibeler.

Zo'n wrapper functie ga ik inderdaat maar eens schrijven, maar dat lost het probleem voor andere PHP developers niet op.

[prototype]

Hacku schreef op dinsdag 30 september 2008 @ 16:27:
[...]


Zeg je dat nu om grappig te willen zijn, of omdat je een hekel hebt aan php?

Beiden vermoed ik

Wat mij misschien nog 't meeste dwars zit echter is dat je hier gewoon direct tegen de mysql functies aan programmeert terwijl met de kleinste moeite je hier een abstractielaag voor hebt kunnen introduceren waarmee postgresql even makkelijk ondersteund kan worden. In plaats daarvan programmeer je concreet aan de mysql functies en zit je ook direct vast aan mysql. Prima opzich als je echt echt echt zeker ervan bent dat mysql is wat de klok blijft slaan bij je, maar zo'n dergelijke abstractielaag kan ook meteen een eenvoudigere API bieden (i.e. compacter) voor het b.v. escapen van je inputwaarden. Dit zou je namelijk gewoon impliciet altijd al kunnen laten gebeuren wanneer mensen een query willen uitvoeren op je abstractielaag.

Verder heb je 't nog over dat de prepared statement een extra roundtrip dient te doen vanuit PHP naar de database server en dat dit extra tijd kost. Mijn vraag hierbij is, heb je wel eens gemeten hoeveel extra tijd dat kost? En sterker nog, heb je wel 's gemeten of dat wel echt de bottleneck is voor je applicatie. Premature optimization is the root of all evil zeg maar, en wanneer je denkt dat het ergens aan ligt, heb je het 9/10 keer fout. Je kan ook beredeneren b.v. dat een prepared statement je snelheidswinst kan opleveren omdat de query al prepared is (en de execution plan voor de database ook al klaar ligt). Dit zou dan evt tot een cache hit kunnen resulteren wat je snelheidsWINST kan geven. Meet nou maar eerst je applicatie voordat je dit soort dingen afschrijft...

[XWB]

Zo'n wrapper functie ga ik inderdaat maar eens schrijven, maar dat lost het probleem voor andere PHP developers niet op.

Een beetje fatsoenlijke php'er heeft dat allemaal in the house, daar zou ik me geen zorgen om maken.

Verder heb je 't nog over dat de prepared statement een extra roundtrip dient te doen vanuit PHP naar de database server en dat dit extra tijd kost. Mijn vraag hierbij is, heb je wel eens gemeten hoeveel extra tijd dat kost? En sterker nog, heb je wel 's gemeten of dat wel echt de bottleneck is voor je applicatie. Premature optimization is the root of all evil zeg maar, en wanneer je denkt dat het ergens aan ligt, heb je het 9/10 keer fout. Je kan ook beredeneren b.v. dat een prepared statement je snelheidswinst kan opleveren omdat de query al prepared is (en de execution plan voor de database ook al klaar ligt). Dit zou dan evt tot een cache hit kunnen resulteren wat je snelheidsWINST kan geven. Meet nou maar eerst je applicatie voordat je dit soort dingen afschrijft...

Volledig eens. Ik heb ooit de verschillen eens gemeten, en dat was verwaarloosbaar.

[ Voor 65% gewijzigd door XWB op 30-09-2008 16:48 ]

[.oisyn]

Olaf van der Spek schreef op dinsdag 30 september 2008 @ 16:35:
[...]

Is dat zo? Waar bewaar je de SQL queries dan? Volgens mij in de PHP code.

Het gaat om de code van "php.exe", niet die van jou script . In feite is de mysql library van PHP niet afhankelijk van de mysql versie (ok, tot op zekere hoogte). Voor prepared statements moet je SQL kunnen ontleden, maar de specifieke syntax van SQL hangt af van de gebruikte mysql versie. Om de parser dus in PHP te stoppen is onhandig, omdat PHP dan elke keer bij een mysql update ook geupdate moet worden. Daarom is een roundtrip naar de daadwerkelijke server handiger.

Hacku schreef op dinsdag 30 september 2008 @ 16:39:
[...]

Anders hou je je persoonlijke vetes buiten deze draad. Ik heb ook mail / DM.

[XWB]

Anders hou je je persoonlijke vetes buiten deze draad. Ik heb ook mail / DM.

Het gaat erom dat je een nogal zinloos bericht geplaatst hebt, en ik me hieraan stoor.

[ Voor 9% gewijzigd door XWB op 30-09-2008 16:50 ]

[RobIII]

Kunnen we het ontopic en gezellig(er) houden verder?

[ Voor 18% gewijzigd door RobIII op 30-09-2008 16:51 ]

[Olaf van der Spek]

prototype schreef op dinsdag 30 september 2008 @ 16:44:
Wat mij misschien nog 't meeste dwars zit echter is dat je hier gewoon direct tegen de mysql functies aan programmeert terwijl met de kleinste moeite je hier een abstractielaag voor hebt kunnen introduceren waarmee postgresql even makkelijk ondersteund kan worden. In plaats daarvan programmeer je concreet aan de mysql functies en zit je ook direct vast aan mysql. Prima opzich als je echt echt echt zeker ervan bent dat mysql is wat de klok blijft slaan bij je, maar zo'n dergelijke abstractielaag kan ook meteen een eenvoudigere API bieden (i.e. compacter) voor het b.v. escapen van je inputwaarden. Dit zou je namelijk gewoon impliciet altijd al kunnen laten gebeuren wanneer mensen een query willen uitvoeren op je abstractielaag.

Ik sta best open voor zo'n abstractielaag hoor. Zeker als die het simpeler in plaats van complexer maakt. Van PDO heb ik bijvoorbeeld wel eens gehoord. Maar ook PDO zie ik niet zoals als safe_query hebben.
Overigens is mysql_query prima te vervangen door een call naar een wrapper lijkt me, als je eens wilt overstappen.

Verder heb je 't nog over dat de prepared statement een extra roundtrip dient te doen vanuit PHP naar de database server en dat dit extra tijd kost. Mijn vraag hierbij is, heb je wel eens gemeten hoeveel extra tijd dat kost?

Nee, dat heb ik niet. Goed punt.
Prepared statement hebben trouwens ook een andere interface voor het benaderen van de resultaten, dus dan dient er nog meer code aangepast te worden.

[Olaf van der Spek]

.oisyn schreef op dinsdag 30 september 2008 @ 16:47:
Daarom is een roundtrip naar de daadwerkelijke server handiger.

Uiteraard. Ik zeg ook niet dat die roundtrip voor prepared statements een slecht idee is. Ik zeg alleen dat dat wel een verschil zou kunnen zijn.

Hacku schreef op dinsdag 30 september 2008 @ 16:46:
Een beetje fatsoenlijke php'er heeft dat allemaal in the house, daar zou ik me geen zorgen om maken.

Het blijft toch code duplicatie? Daar hebben ze libs voor uitgevonden, copy/paste is geen goede oplossing.
En in elk project een net iets andere wrapper lijkt me ook niet handig.

Het gaat er ook niet om dat ik zo'n wrapper wel kan schrijven. Het gaat erom dat elke beginnende developer zo'n functie ook zelf zal moeten vinden / schrijven. En dat gebeurd gewoon niet. Zelfs de PHP documentatie bevat volgens mij geen link naar zo'n wrapper.

[ Voor 53% gewijzigd door Olaf van der Spek op 30-09-2008 17:00 ]

[prototype]

Olaf van der Spek schreef op dinsdag 30 september 2008 @ 16:53:
[...]

Ik sta best open voor zo'n abstractielaag hoor. Zeker als die het simpeler in plaats van complexer maakt. Van PDO heb ik bijvoorbeeld wel eens gehoord. Maar ook PDO zie ik niet zoals als safe_query hebben.
Overigens is mysql_query prima te vervangen door een call naar een wrapper lijkt me, als je eens wilt overstappen.

Ik heb al een hele tijd niet meer in PHP gewerkt, maar met een beetje logica zou ik zeggen dat je ook voor PDO een wrapper zou kunnen schrijven indien je zulke dingen mist. In het bijzouder zou ik je bridge/strategy pattern en facade pattern willen aanraden. Beiden beschreven in design pattern boek van gang of four. Met bridge/strategy pattern zou je van database provider kunnen swappen, terwijl de facade pattern je eenvoudige interface kan bieden die onderwater de complexe dingen voor je afhandelt (zoals het escapen voordat je een query daadwerkelijk doet, en dat ook op de juiste database provider).

[...]

Nee, dat heb ik niet. Goed punt.
Prepared statement hebben trouwens ook een andere interface voor het benaderen van de resultaten, dus dan dient er nog meer code aangepast te worden.

Facade pattern... een goede abstractielaag is er een die dit soort details weglaat voor de programmeur.

[Olaf van der Spek]

prototype schreef op dinsdag 30 september 2008 @ 16:58:
Facade pattern... een goede abstractielaag is er een die dit soort details weglaat voor de programmeur.

Een aantal personen in dit topic lijkt daar het nut niet van in te zien.

[XWB]

Olaf van der Spek schreef op dinsdag 30 september 2008 @ 16:55:
Het blijft toch code duplicatie? Daar hebben ze libs voor uitgevonden, copy/paste is geen goede oplossing.
En in elk project een net iets andere wrapper lijkt me ook niet handig.

Zo'n database class kost echt niet veel moeite om te implementeren, vooral goed nadenken erover. En ik heb liever mijn eigen scripts, dan andermans libs.

[prototype]

Olaf van der Spek schreef op dinsdag 30 september 2008 @ 17:02:
[...]

Een aantal personen in dit topic lijken daar het nut niet van in te zien.

Ik denk dat de meesten het hier wel mee eens zullen zijn hoor ;-) (of begin ik nu naast m'n schoenen te lopen). Ze bedoelen het allemaal goed, maar de meeste suggesties die zijn voorgedragen heb je al afgedaan zonder ze te bestuderen. Facade pattern is er al een b.v. die al meerdere keren in deze topic is genoemd, en niet alleen door mij (alhoewel ik 't beestje wel direct bij z'n naam heb genoemd).

Een van de dingen die resulteert in goede code is het besef van een programmeur dat deze tegen een interface dient aan te programmeren en niet tegen de implementatie. Wat dit inhoudt is dat een programmeur goede kennis moet hebben van abstractie en compositie. Met eerstgenoemde dien je dus te weten dat wanneer je iets abstracter benaderd, het in algemene zin dus, relevantie kan hebben voor meerdere dingen. Wanneer ik bijvoorbeeld vraag of er mensen van appels houden, krijg ik misschien meer handen in de lucht wanneer ik vraag of er mensen zijn die van fruit houden. Dezelfde analogie kan je met code doen, in de zin dat je kan vragen of je wil werken met mysql of gewoon met EEN SQL (let wel op dat er onderlinge verschillen zijn tussen de SQL's, en dat je dus een subset ervan moet hebben die door iedereen ondersteund wordt).

Verder hebben we het nog over compositie, hoe je code met elkaar relateert. Welke bouwstenen kan ik onderscheiden in een programma en eventueel gebruiken voor andere projecten ook? Oftewel, wat is de compositie van een applicatie en welke modules kan ik erin onderscheiden die ik voor andere projecten eventueel ook zou kunnen gebruiken. Dit zorgt voor onderhoudbaarheid. Wanneer je dit soort principes leert aan een beginnende programmeur hoef je niet bang te zijn dat ze niet begrijpen wat je doet wanneer je een design pattern introduceert als facade en bridge/strategy. Je kan nu namelijk al raden wat de filosofie is van facade en de filosofie van bridge/strategy...

Laatste punt: DOCUMENTATIE. Goede code heeft naar mijn ervaring een opmaak van 60% documentatie, 40% code (!!!). Meer documentatie dus dan code. Let wel op: niet te granulair documenteren, dat verslechtert leesbaarheid. Doe het op API niveau en op implementatie niveau alleen bij code die echt lastig te begrijpen is zonder die documentatie (b.v. voor lusinvarianten)

[ Voor 7% gewijzigd door prototype op 30-09-2008 17:14 ]

[Olaf van der Spek]

Hacku schreef op dinsdag 30 september 2008 @ 17:08:
Zo'n database class kost echt niet veel moeite om te implementeren, vooral goed nadenken erover. En ik heb liever mijn eigen scripts, dan andermans libs.

Het not-invented-here syndroom?
Of zijn andermans libs van zo'n slechte kwaliteit?

[XWB]

Olaf van der Spek schreef op dinsdag 30 september 2008 @ 17:30:
[...]

Het not-invented-here syndroom?
Of zijn andermans libs van zo'n slechte kwaliteit?

Veel libs zijn gewoon één hoop ranzige code, of hebben veel zaken aan boord die ik niet nodig heb, of werken niet op de manier zoals ik het wil. En wat als er iets mis gaat, dan mag je lopen zoeken waar het mis gaat. En dan pas je wat aan, is er wat anders stuk. Eigen libs doen 100% wat ik wil, en die kan ik altijd makkelijk aanpassen/uitbreiden indien nodig.

Dat geldt niet alleen voor php, ook voor javascript. Denk maar niet dat ik ooit die prototype.js zal gebruiken, ik heb gewoon m'n eigen scripts.

[prototype]

Hacku schreef op dinsdag 30 september 2008 @ 17:35:
[...]


Veel libs zijn gewoon één hoop ranzige code, of hebben veel zaken aan boord die ik niet nodig heb, of werken niet op de manier zoals ik het wil. En wat als er iets mis gaat, dan mag je lopen zoeken waar het mis gaat. En dan pas je wat aan, is er wat anders stuk. Eigen libs doen 100% wat ik wil, en die kan ik altijd makkelijk aanpassen/uitbreiden indien nodig.

Dat geldt niet alleen voor php, ook voor javascript. Denk maar niet dat ik ooit die prototype.js zal gebruiken, ik heb gewoon m'n eigen scripts.

Mag ik vragen waarom je wel PHP gebruikt dan? Dat is immers ook een code base die niet geheel van jouw hand komt ;-)
Ik vind het dan ook niet veel houdt snijden. Voor elke programmeur die slechter dan jou is, zijn er ook genoeg programmeurs die beter zijn, dus ik zou het niet zo snel generaliseren. Houd dat in 't achterhoofd, dat houdt je ook meteen bescheiden ;-)

[XWB]

Mag ik vragen waarom je wel PHP gebruikt dan?

Omdat php het best past bij mijn doeleinden. Meer ga ik daar niet op zeggen, discussie "welke taal moet je nemen" heeft al 1001 maal plaatsgevonden

Dat is immers ook een code base die niet geheel van jouw hand komt ;-)

En C# heb ik ook niet ontworpen, terwijl ik er vroeger wel met gewerkt heb. Overdrijven is een vak

Voor elke programmeur die slechter dan jou is,

De meeste libs passen niet bij mij, doen niet wat ik wil, moet ik zelf aanpassen e.d. Voor eigen gemak bouw ik alles zelf, dat is achteraf veel makkelijker werken. Nergens zeg ik een perfecte programmeur te zijn.

[Olaf van der Spek]

prototype schreef op dinsdag 30 september 2008 @ 17:10:
maar de meeste suggesties die zijn voorgedragen heb je al afgedaan zonder ze te bestuderen. Facade pattern is er al een b.v. die al meerdere keren in deze topic is genoemd, en niet alleen door mij (alhoewel ik 't beestje wel direct bij z'n naam heb genoemd).

Dat ik de meeste suggesties heb afgedaan zonder ze te besturen zou ik niet willen zeggen. Prepared statements heb ik misschien te vroeg in de ijskast gestopt, maar ik ga toch eerst voor de eigen wrapper.
Ik vind dit echter nog steeds een work around, geen oplossing. Zo'n 'wrapper' zou standaard in elke PHP installatie moeten zitten.

Het direct gebruiken van mysql_query vind ik trouwens helemaal geen probleem. Dat is de minste zorg als ik ook nog eens een andere DB zou willen ondersteunen.

[prototype]

Hacku schreef op dinsdag 30 september 2008 @ 17:51:
[...]
De meeste libs passen niet bij mij, doen niet wat ik wil, moet ik zelf aanpassen e.d. Voor eigen gemak bouw ik alles zelf, dat is achteraf veel makkelijker werken. Nergens zeg ik een perfecte programmeur te zijn.

De reden waarom ik dit aankaart is omdat, als je in teamverband werkt, zo'n instelling niet goed gaat werken. Sure, voor eigen gemak, maar het is ook een kunst om de code te kunnen lezen en mogelijk verbeteren van anderen. Verder noem je zoiets als prototype.js, nu vind ik dat nog niet eens zo rampzalig geschreven, maar laten we even veronderstellen dat het wel zo zou zijn. De interface van prototype.js is nagenoeg dezelfde als die van moo js lib. Alleen dit feit al zou het niet moeilijk moeten maken om van de ene library naar de andere library te stappen (zelfs eventueel je eigen). Het is dermate onpragmatisch imho echter om een van scratch te schrijven. Again, als jij consistent goed tegen een interface aan programmeert dan moet het geen probleem zijn om de implementatie te veranderen naar een die in jouw mening 'beter' is. Overigens flame ik hier niet op PHP en zeg ik ook nergens dat je gezegd hebt dat je de perfecte programmeur bent ;-)

[ Voor 17% gewijzigd door prototype op 30-09-2008 17:58 ]

[prototype]

Olaf van der Spek schreef op dinsdag 30 september 2008 @ 17:55:
[...]

Dat ik de meeste suggesties heb afgedaan zonder ze te besturen zou ik niet willen zeggen. Prepared statements heb ik misschien te vroeg in de ijskast gestopt, maar ik ga toch eerst voor de eigen wrapper.
Ik vind dit echter nog steeds een work around, geen oplossing. Zo'n 'wrapper' zou standaard in elke PHP installatie moeten zitten.

Het direct gebruiken van mysql_query vind ik trouwens helemaal geen probleem. Dat is de minste zorg als ik ook nog eens een andere DB zou willen ondersteunen.

Alleen omdat zoiets niet standaard in de standard library zit wil het nog niet zeggen dat het een workaround is Volgens die zelfde beredenering zou er ook een make_forum() of make_blog() functie in de standard library moeten zitten omdat de meesten dat ook gebruiken icm PHP Maar zou PDO niet als een abstractie dienen te werken voor de diverse databases? Die zit wel degelijk in de standard library iirc en het is dan ook een kwestie van de available drivers hebben ( http://nl.php.net/manual/en/pdo.getavailabledrivers.php ) dan. Als je hier nog een facade omheen bouwt dan zou dat de meeste, danwel al je problemen moeten verhelpen.

Bovendien onderschat je denk ik de verschillen tussen de manieren waarop databases hun api functies in PHP hebben. Kijk maar eens bijvoorbeeld hoe je data moet escapen in postgresql en vergelijk dat eens met de mysql variant. Subtiel anders, maar anders nonetheless. Je kan niet zomaar een search en replace doen dus, omdat je er dan al van uit gaat dat er voor elke functie van mysql een exacte tegenpool is in postgresql. Het is dan ook de kunst om te abstraheren op een subset van deze functionaliteit, i.e. die zowel mysql als postgresql hebben.

[ Voor 11% gewijzigd door prototype op 30-09-2008 18:04 ]

[XWB]

De reden waarom ik dit aankaart is omdat, als je in teamverband werkt, zo'n instelling niet goed gaat werken.

Dat weet ik. Dat is een ander verhaal, dan worden er ook afspraken gemaakt.

Het is dermate onpragmatisch imho echter om een van scratch te schrijven.

Ja, maar dan kom ik weer bij mijn eerder genoemd punt:

of hebben veel zaken aan boord die ik niet nodig heb

90% van prototype zou ik toch niet gebruiken, de lib die ik dus schrijf is dan ook vele malen kleiner. En als je later toch wat extra nodig hebt, dan kan je dat eenvoudig toevoegen.

[Olaf van der Spek]

prototype schreef op dinsdag 30 september 2008 @ 18:02:
Alleen omdat zoiets niet standaard in de standard library zit wil het nog niet zeggen dat het een workaround is Volgens die zelfde beredenering zou er ook een make_forum() of make_blog() functie in de standard library moeten zitten omdat de meesten dat ook gebruiken icm PHP

Hoeveel % van de scripts gebruikt make_forum dan?

Maar zou PDO niet als een abstractie dienen te werken voor de diverse databases? Die zit wel degelijk in de standard library iirc en het is dan ook een kwestie van de available drivers hebben ( http://nl.php.net/manual/en/pdo.getavailabledrivers.php ) dan. Als je hier nog een facade omheen bouwt dan zou dat de meeste, danwel al je problemen moeten verhelpen.

Dat klinkt allemaal heel ingewikkeld voor de simpele functionaliteit die ik graag zou willen hebben. Maar het kan best een goed idee zijn.

Bovendien onderschat je denk ik de verschillen tussen de manieren waarop databases hun api functies in PHP hebben. Kijk maar eens bijvoorbeeld hoe je data moet escapen in postgresql en vergelijk dat eens met de mysql variant. Subtiel anders, maar anders nonetheless. Je kan niet zomaar een search en replace doen dus, omdat je er dan al van uit gaat dat er voor elke functie van mysql een exacte tegenpool is in postgresql. Het is dan ook de kunst om te abstraheren op een subset van deze functionaliteit, i.e. die zowel mysql als postgresql hebben.

Dat zou best eens kunnen, ik heb eerlijk gezegd nog nooit PostgreSQL gebruikt. Shame on me.
Maar ik kan me niet voorstellen dat een goede abstractie van MySQL niet voor PostgreSQL zou werken. Of eenvoudig is om te bouwen.

[prototype]

Hacku schreef op dinsdag 30 september 2008 @ 18:04:
[...]


Dat weet ik. Dat is een ander verhaal, dan worden er ook afspraken gemaakt.


[...]


Ja, maar dan kom ik weer bij mijn eerder genoemd punt:


[...]


90% van prototype zou ik toch niet gebruiken, de lib die ik dus schrijf is dan ook vele malen kleiner. En als je later toch wat extra nodig hebt, dan kan je dat eenvoudig toevoegen.

Deert het dat de code er alsnog in zit en je het niet gebruikt? :-) Dezelfde beredenering kan je dus weer herhalen voor PHP, daar zitten ook zoveel standaard functies in, en je gebruikt er slechts een handje vol van. Moet je om deze reden dan PHP opnieuw gaan implementeren of strippen van de functies die je niet gebruikt? En wat nou als je plotseling die functies wel nodig hebt?

Kijk, als de code die je niet gebruikt een dermate hoge performance penalty met zich meebrengen dan kan je daar wel wat voor zeggen in het geval van prototypejs. Maar VM's zijn tegenwoordig ook slim genoeg om te weten wat ze wel en niet kunnen verwaarlozen. Zulke beslissingen moet je dan ook pas maken wanneer je echt merkt dat het een probleem wordt. En dat is dan ook meteen mijn punt met tegen interfaces aan programmeren. Als jij tegen de interface van prototypejs aancode, die qua features heel erg compleet is, en je merkt dat het TE compleet is, dan vervang je de prototype js implementatie gewoon met je eigen, of stript prototype js van functionaliteit waar je zeker van bent dat je die nooit zult gebruiken. Het is dermate onpragmatisch echter om 't niet op deze volgorde te doen imho.

Bijkomend voordeel van een bestaande lib gebruiken: de implementatie wordt onderhouden door anderen ook. Je krijgt dus ook meteen gratis bugfixes op dezelfde manier zoals ik dat net zei (gratis in de zin van met minimale moeite).

[ Voor 6% gewijzigd door prototype op 30-09-2008 18:15 ]

[XWB]

Wat mij misschien nog 't meeste dwars zit echter is dat je hier gewoon direct tegen de mysql functies aan programmeert terwijl met de kleinste moeite je hier een abstractielaag voor hebt kunnen introduceren waarmee postgresql even makkelijk ondersteund kan worden.

postgresql, die staat ook op mijn todo om ooit eens te proberen (helaas heb ik een todo lijst die eindeloos lijkt). Het is en blijft jammer dat er zo weinig hosters postgresql aanbieden.

[prototype]

Olaf van der Spek schreef op dinsdag 30 september 2008 @ 18:08:
[...]

Hoeveel % van de scripts gebruikt make_forum dan?

De meesten bouwen een forum of blog met php. Alleen omdat het vaak gebruikt wordt, wil het nog niet zeggen dat het perse in de stdlib moet van welke programmeertaal dan ook. De reden waarom zoiets in 't geval van PHP met databases b.v. er niet in zit is denk ik vrij triviaal: je kan niet rekening houden met elke database (iedereen kan er in feite namelijk een schrijven en er bindings voor maken voor PHP), welliswaar wel met de meest populaire. Maar dit kan tot verwarring leiden en evt liskov substitution principle wanneer je een database gebruikt die b.v. niet populair wordt geacht door de mensen van PHP om op te nemen in de "standaard abstractie lib". Je zou dan ook je eigen driver adapter aan moeten leveren voor die abstractie lib en goh, aan het einde van de dag ben je dus ongeveer even veel tijd kwijt

[...]

Dat klinkt allemaal heel ingewikkeld voor de simpele functionaliteit die ik graag zou willen hebben. Maar het kan best een goed idee zijn.

Een klein beetje tijd zul je hoe dan ook moeten investeren, maar ik kan je nu al zeggen dat het echt geen rocket science is. Het zal me dan ook verbazen als er geen open source variant al voor je klaar staat op het internet.

[...]

Dat zou best eens kunnen, ik heb eerlijk gezegd nog nooit PostgreSQL gebruikt. Shame on me.
Maar ik kan me niet voorstellen dat een goede abstractie van MySQL niet voor PostgreSQL zou werken. Of eenvoudig is om te bouwen.

Als jij alles met mysql_* aanroept, en jij gaat postgresql op een gegeven moment gebruiken, dan kan je niet zomaar even alles wat met mysql_ begint ervangen met pgsql_ en vice versa. Dat is mijn punt, en daarmee wil ik 't benadrukken dat een abstractielaag gebruiken een heel goed idee is in zulke gevallen die met heel weinig moeite bewerkstelligd zijn. Om mijn punt helemaal duidelijk te maken, vergelijk de API eens van http://nl3.php.net/pgsql en http://nl3.php.net/mysql . Het is de kunst dus om een abstractie te bedenken die beiden kunnen zij het met meer of minder function calls onderwater.

[ Voor 17% gewijzigd door prototype op 30-09-2008 18:29 ]

[Anoniem: 156876]

Google: "mysql_query_safe"

Levert naast dit topic, het volgende op:

PHP:

function mysql_query_safe()
{
    $args    = func_get_args();
    $query   = array_shift($args);
    $args    = array_map('mysql_real_escape_string', $args);
    return mysql_query(vsprintf($query, $args));
}

Ik verwacht dat je deze ooit ergens gezien, van gehoord of gelezen hebt?

Hacku schreef op dinsdag 30 september 2008 @ 18:10:
[...]


postgresql, die staat ook op mijn todo om ooit eens te proberen (helaas heb ik een todo lijst die eindeloos lijkt). Het is en blijft jammer dat er zo weinig hosters postgresql aanbieden.

Als je weet dat dat "probleem" er is, dan zoek je toch naar een host die het wél ondersteund?
Google: "hosting postgresql"


Verder PDO, of anders gebruik ik welles een oplossing als:

PHP:

$blaat = '"; DROP TABLE crap; --';
$nummertje = 10;
$query = sprintf('INSERT
                  INTO
                    crap
                  SET
                    blaat = "%s",
                    nummertje = %d;',
                  mysql_real_escape_string($blaat),
                  $nummertje
                 );

[Olaf van der Spek]

Anoniem: 156876 schreef op dinsdag 30 september 2008 @ 18:25:
Ik verwacht dat je deze ooit ergens gezien, van gehoord of gelezen hebt?

Damn, nee, maar dat is dus bijna precies wat ik bedoel. Alhoewel "$query = array_shift($args); " volgens mij zonder "$args = " moet zijn.
Hartelijk dank. En deze zou dus standaard in PHP moeten zitten.

[ Voor 7% gewijzigd door Olaf van der Spek op 30-09-2008 18:40 ]

[NMe]

Olaf van der Spek schreef op dinsdag 30 september 2008 @ 18:39:
[...]

Hartelijk dank. En deze zou dus standaard in PHP moeten zitten.

Er zit standaard iets beters in PHP dat jij nu dus gaat vervangen door een zelfgemaakte functie die benadert wat de PHP-functionaliteit allang kan. Ach, als je daar vrolijk van wordt, dan moet je het doen.

[curry684]

Anoniem: 156876 schreef op dinsdag 30 september 2008 @ 18:25:
Google: "mysql_query_safe"

Levert naast dit topic, het volgende op:

PHP:

function mysql_query_safe()
{
    $args    = func_get_args();
    $query   = array_shift($args);
    $args    = array_map('mysql_real_escape_string', $args);
    return mysql_query(vsprintf($query, $args));
}

Ik verwacht dat je deze ooit ergens gezien, van gehoord of gelezen hebt?

En ik mag geen null values of formules gebruiken?

[Anoniem: 156876]

curry684 schreef op dinsdag 30 september 2008 @ 20:32:
[...]

En ik mag geen null values of formules gebruiken?

Jawel hoor, niemand zegt dat je dat moet gebruiken. Het was alleen de oplossing waar de TS naar op zoek was, niet dé oplossing.

[Voutloos]

En zolang je niet in $query om elke variabele quotes zet is het zelfs ook niet de oplossing tegen sql injection. En als je dat wel doet, heb je geen sql injection mogelijkheid, maar ben je consistent de helft van je variabelen in het verkeerde datatype aan het zetten.

Die functie is dus gewoon bijzonder kort door de bocht. Lees: let op wat meer aspecten en die functie is gewoon ronduit k*t.

Of nog wat duidelijker: met mysql_real_escape_string() op iets dat geen string is (dwz niet binnen quotes staat in de query) helpt dus onvoldoende tegen injection. Hmz, misschien is die functie wel bedoeld voor het echt escapen van strings in een mysql context.

[ Voor 26% gewijzigd door Voutloos op 30-09-2008 21:28 ]

[LauPro]

Sowieso vind ik het altijd opmerkelijk dat mysql-users van bijv. frontends de rechten zouden moeten hebben om een tabel te droppen. Dat is gewoon sowieso al een configuratiefout op de webserver/databaseserver.

DeX schreef op woensdag 01 oktober 2008 @ 17:23:


En ja hij is oud. Re-posts op zijn tijd zijn belangerijk.

Verder is dit absoluut niet iets waar PHP zich zou mee moeten bemoeien. PHP moet met zijn poten van de content van variabelen afblijven, daar hebben ze in het verleden met magic_quotes en aanverwanten al genoeg ellende mee veroorzaakt.

Het escapen is de verantwoordelijkheid van de programmeur. En ik zou altijd een DAL gebruiken om te praten met een DB, juist om dit soort rotzooi te voorkomen.

[ Voor 18% gewijzigd door LauPro op 01-10-2008 22:59 ]

[curry684]

Ben het ook eens met LauPro in deze - het probleem in deze is voor de aardigheid een keer niet dat PHP een stomme taal is met tig fundamentele ontwerpfouten, maar het IQ van de mensen die denken te kunnen programmeren na een tutorial van 5 regels. Als je wil voorkomen dat mensen zich in de voet schieten moet je ze geen geweer geven als ze er niets van snappen, niet de loop dichtlassen.

[LauPro]

Het amateurisme in een sector is nog nooit zo groot geweest. Een tijdje terug sprak ik met iemand die zei dat 'wij' (de ICT-sector) de kerkenbouwers zijn van honderden jaren geleden. Daar ging ook vreselijk veel mis met veelal een dodelijke afloop, denk aan projecten die soms tientallen jaren duurden en waar vele architecten op hebben gezeten.

Gelukkig is het hedendaags allemaal niet zo dramatisch, hooguit hier en daar publiekelijke boetedoening. Mensen die ignorant blijven en volharden kortzichtige ontwikkelstrategieën zullen aan het einde van de rit keihard tegen de spreekwoordelijke doch ambivalente LAMP lopen.

Tegelijkertijd moeten mensen die wél verstand van zaken hebben en projecten aannemen waarbij puinruimen een significant onderdeel is niet zeuren. Ze kunnen immers een zeer pittig uurtarief rekenen voor hun verdiensten.

[/ratel]

[curry684]

Projecten die bij ons binnenkomen waarbij de samenvatting 'puinruimen' is doen we gewoon alleen als we het from scratch goed mogen doen - en dat gebeurt vaak ook.

[Olaf van der Spek]

-NMe- schreef op dinsdag 30 september 2008 @ 19:51:
Er zit standaard iets beters in PHP dat jij nu dus gaat vervangen door een zelfgemaakte functie die benadert wat de PHP-functionaliteit allang kan. Ach, als je daar vrolijk van wordt, dan moet je het doen.

Heb je het nog steeds over die prepared statements?
Aangezien de query syntax daarvan overeenkomt met mijn eigen functie lijkt mijn functie geen onlogische eerste stap.
Als ik daarna zin heb om nog veel meer te sleutelen zal ik eens naar die prepared statements kijken.

[Olaf van der Spek]

curry684 schreef op dinsdag 30 september 2008 @ 20:32:
En ik mag geen null values of formules gebruiken?

Waarom zou je dat met die functie niet kunnen?

[Olaf van der Spek]

Voutloos schreef op dinsdag 30 september 2008 @ 21:11:
En zolang je niet in $query om elke variabele quotes zet is het zelfs ook niet de oplossing tegen sql injection. En als je dat wel doet, heb je geen sql injection mogelijkheid, maar ben je consistent de helft van je variabelen in het verkeerde datatype aan het zetten.

PHP:

function db_query_safe($s)
{
    $d = '';
    $v = func_get_args();
    $a = 0;
    while ($a < strlen($s))
    {
        $b = strpos($s, '?', $a);
        if ($b === false)
            break;
        array_shift($v);
        $d .= substr($s, $a, $b - $a);
        if (is_int($v[0]))
            $d .= $v[0];
        else
            $d .= '\'' . mysql_real_escape_string($v[0]) . '\'';
        $a = $b + 1;
    }
    return db_query($d . substr($s, $a));
}

[curry684]

Olaf van der Spek schreef op woensdag 01 oktober 2008 @ 22:53:
[...]

Waarom zou je dat met die functie niet kunnen?

Omdat die functie als jij een string value wil inserten iets moet krijgen als volgt:

PHP:

mysql_query_safe("INSERT MyTable VALUES ('%s')", 'null');

En dan staat de string null ineens in je DB ipv het gewenste effect.

[Olaf van der Spek]

LauPro schreef op woensdag 01 oktober 2008 @ 01:11:
Sowieso vind ik het altijd opmerkelijk dat mysql-users van bijv. frontends de rechten zouden moeten hebben om een tabel te droppen. Dat is gewoon sowieso al een configuratiefout op de webserver/databaseserver.

Ook zonder DDL is er met SQL injectie genoeg schade aan te richten.

Verder is dit absoluut niet iets waar PHP zich zou mee moeten bemoeien. PHP moet met zijn poten van de content van variabelen afblijven, daar hebben ze in het verleden met magic_quotes en aanverwanten al genoeg ellende mee veroorzaakt.

Het escapen is de verantwoordelijkheid van de programmeur. En ik zou altijd een DAL gebruiken om te praten met een DB, juist om dit soort rotzooi te voorkomen.

Magic quotes is inderdaad een ramp. Maar dit is gewoon een functie die je mag gebruiken. Niet moet. Wat is daar het probleem van?

[Olaf van der Spek]

curry684 schreef op woensdag 01 oktober 2008 @ 22:56:
Omdat die functie als jij een string value wil inserten iets moet krijgen als volgt:

PHP:

mysql_query_safe("INSERT MyTable VALUES ('%s')", 'null');

En dan staat de string null ineens in je DB ipv het gewenste effect.

Ah, zo. Dat is vast wel op te lossen.

[ Voor 10% gewijzigd door Olaf van der Spek op 01-10-2008 23:00 ]

[curry684]

En waarom met die andere code niet of mis ik nu iets?

edit:
je was er al achter

[ Voor 26% gewijzigd door curry684 op 01-10-2008 23:01 ]

[Olaf van der Spek]

curry684 schreef op woensdag 01 oktober 2008 @ 01:21:
Ben het ook eens met LauPro in deze - het probleem in deze is voor de aardigheid een keer niet dat PHP een stomme taal is met tig fundamentele ontwerpfouten, maar het IQ van de mensen die denken te kunnen programmeren na een tutorial van 5 regels. Als je wil voorkomen dat mensen zich in de voet schieten moet je ze geen geweer geven als ze er niets van snappen, niet de loop dichtlassen.

Daar heb je wel gelijk in, maar ik krijg toch vaak de indruk dat mensen het niet te eenvoudig willen maken om dingen veilig te doen. En dat vind ik jammer.

[BCC]

Er zijn toch dingen als PHP cake? Die doen exact wat jij mist in PHP, maar dan netjes in een framework (waar het ook hoort imho).

[LauPro]

Olaf van der Spek schreef op woensdag 01 oktober 2008 @ 22:55:

PHP:

function db_query_safe($s)
{
    // [crap]
}

Als ik dit soort constructies weer zie dan springen spontaan de tranen in mijn ogen. Hiermee kan je echt niet thuiskomen hor! Waarom escape je die array niet eerst en gebruik je gewoon de embedded functies uit php om daarmee een query te compileren.

Olaf van der Spek schreef op woensdag 01 oktober 2008 @ 22:56:
[...]
Ook zonder DDL is er met SQL injectie genoeg schade aan te richten.

Met DDL-rechten blaas je het huis op van zijn fundament, zonder DDL-rechten gooi je een raam in, inderdaad niet zo'n groot verschil.

Magic quotes is inderdaad een ramp. Maar dit is gewoon een functie die je mag gebruiken. Niet moet. Wat is daar het probleem van?

Misschien ten overvloede: Magic quotes is juist geïntroduceerd om voor 'newbies' o.a. SQL-injecties te voorkomen, helaas kan door onjuist gebruik kan het probleem met magic_quotes alleen maar erger worden en zit men met valse verwachtingen en verminkte code. Het is verder een vervloekt onderdeel dat nu zelfs door de ontwikkelaars van PHP zelf getracht wordt uit te faseren.

[Olaf van der Spek]

BCC schreef op woensdag 01 oktober 2008 @ 23:06:
Er zijn toch dingen als PHP cake? Die doen exact wat jij mist in PHP, maar dan netjes in een framework (waar het ook hoort imho).

Eh, nee. Ik verwacht zoiets in een library, niet in een framework.

LauPro schreef op woensdag 01 oktober 2008 @ 23:17:
Als ik dit soort constructies weer zie dan springen spontaan de tranen in mijn ogen. Hiermee kan je echt niet thuiskomen hor! Waarom escape je die array niet eerst en gebruik je gewoon de embedded functies uit php om daarmee een query te compileren.

Omdat ik niet ieder array element escape. Anders was array_map inderdaad handiger.
Is er een functie die elk '?' in een string kan vervangen door een array element? Zo ja, dan hoor ik dat graag.

Met DDL-rechten blaas je het huis op van zijn fundament, zonder DDL-rechten gooi je een raam in, inderdaad niet zo'n groot verschil.

Alle data kwijt of alle data en de structuren kwijt. Vind ik niet zo'n groot verschil nee.

[ Voor 23% gewijzigd door Olaf van der Spek op 01-10-2008 23:31 ]

[Gomez12]

Olaf van der Spek schreef op woensdag 01 oktober 2008 @ 23:03:
[...]
Daar heb je wel gelijk in, maar ik krijg toch vaak de indruk dat mensen het niet te eenvoudig willen maken om dingen veilig te doen. En dat vind ik jammer.

Dit komt imho voornamelijk omdat eenvoudig veilig een afweging is die ertoe kan leiden dat niet super-eenvoudig opeens doorschiet naar de category moeilijk omdat je eerst om de eenvoudige beveiligingen heen moet.

Ze hebben het ooit eens geprobeerd zoals jij het wenst te hebben met magic_quotes etc, praktisch levert dit soort constructies gewoon meer problemen op dan het oplost.

Loose-typing en user-input alleen maar binnenkrijgen als strings betekent gewoon een extra controle voor je het naar je dbase stuurt.
Als jij iets binnenkrijgt als '1' kan php niet voor jou gaan uitmaken of je dan een string een int een float of een boolean bedoelt, dit weet je dbase wel en de progger ook.

[LauPro]

Olaf van der Spek schreef op woensdag 01 oktober 2008 @ 23:29:
Eh, nee. Ik verwacht zoiets in een library, niet in een framework.

Er zijn zat DBL's die als losse library kunnen functioneren.

Omdat ik niet ieder array element escape. Anders was array_map inderdaad handiger.
Is er een functie die elk '?' in een string kan vervangen door een array element? Zo ja, dan hoor ik dat graag.

Bd:

PHP:

function custom_escape($s) {
  if (is_int($s)) {
    return $s;
  // todo: float etc
  }else{
    return mysql_real_escape_string($s);
  }
}


$sSQL = "insert into T (A, B, C) values ('%s', %s, %s)";
$aParams = array('test123',10,9.4);
$aEscapedParams = array_map('custom_escape',$aParams);
mysql_query(vsprintf($sSQL, $aEscapedParams));

Zoiets zou ik doen.

Alle data kwijt of alle data en de structuren kwijt. Vind ik niet zo'n groot verschil nee.

Meningsverschil.

[Olaf van der Spek]

LauPro schreef op woensdag 01 oktober 2008 @ 23:40:
Er zijn zat DBL's die als losse library kunnen functioneren.

Gelukkig maar.

Zoiets zou ik doen.
[...]
Meningsverschil.

%s voor een int?
Ik heb ervoor gekozen ? in plaats van '%s' te gebruiken, anders is vsprintf inderdaad goed bruikbaar.

Meningsverschil? Dat meen je toch niet serieus?

[ Voor 19% gewijzigd door Olaf van der Spek op 01-10-2008 23:54 ]

[LauPro]

Olaf van der Spek schreef op woensdag 01 oktober 2008 @ 23:48:
%s voor een int?
Ik heb ervoor gekozen ? in plaats van '%s' te gebruiken, anders is vsprintf inderdaad goed bruikbaar.

Ik heb het even snel in elkaar gebreid, het zou mij niets verbazen dat deze constructie als zodanig door PHP gewoon wordt uitgevoerd. Die andere vormen van formatting zijn eigenlijk alleen maar interessant als je een bepaalde precisie of presentatie wil, om te praten met MySQL is dat verder niet relevant.

Meningsverschil? Dat meen je toch niet serieus?

Het is beide even erg, ware het niet dat de DROP TABLE-varianten tegenwoordig ook al door sommige bots worden getest. En voor een outsider is het zeer lastig om de DDL te raden voor specifieke queries. Je zou zelfs kunnen denken dat een webuser geen DELETE-rechten op bepaalde tabellen mag hebben (want dat doe je bijv. via een backend).

Ik kan hier niet het meest optimale securitymodel voorschotelen, de essentie is iig wel dat deze niet bestaat uit lucullische rechten.

[XWB]

PHP:

if (is_int($s))

Note, waarden uit $_GET en $_POST zijn standaard een string, en dan krijg je sowieso een false terug. is_numeric() kan je ook gebruiken voor strings, ofwel moet je de waarden eerst casten naar een int.

[LauPro]

Hacku schreef op donderdag 02 oktober 2008 @ 00:00:

PHP:

if (is_int($s))

Note, waarden uit $_GET en $_POST zijn standaard een string, en dan krijg je sowieso een false terug. is_numeric() kan je ook gebruiken voor strings, ofwel moet je de waarden eerst casten naar een int.

Ik ben met je eens dat de hele constructie geen schoonheidsprijs verdiend. Persoonlijk gebruik ik een abstractielaag voor userinput waarbij alle waarden naar de juisten types worden gecast. Daarna vindt er een validatie en eventueel een bewerking plaats, waarna de waardes via een databaselaag uiteindelijk in de DB terecht komen.

Er is geen generieke oplossing voor dit probleem, enkel het gebruiken van een DBL welke geparameteriseerde syntax heeft ipv queried.

[Gomez12]

LauPro schreef op woensdag 01 oktober 2008 @ 23:55:
[...]
Je zou zelfs kunnen denken dat een webuser geen DELETE-rechten op bepaalde tabellen mag hebben (want dat doe je bijv. via een backend).

Of gewoon verschillende webusers verschillende rechten geven. Bijv op GoT hoef een gewone user afaik nergens delete rechten te hebben, edit rechten alleen op de losse posts, niet op de topics tabel.
Mod krijgt andere webuser toegewezen die wel edit rechten op topics tabel heeft, maar nog geen delete rechten op posts ( dit wordt via een apart veldje bijv geregeld )
Dit is nog wel iets verder uit te breiden met global mod etc. maar in de praktijk gok ik dat dat totaal niet nodig is ( mods zijn al trusted users dus die kan je in dbase meer rechten geven en dan in web de restricties toepassen )

In wezen kan ik me gewoon maar heel weinig situaties voorstellen waarin een random user delete rechten op een dbase nodig heeft. Een paar extra rijen in een tabel schrik ik niet echt van. Het niet meer tonen van een topic / post voor een user is perfect te doen met een deleted kolommetje, gooi hier een last modified field aanvast en het ergste wat er kan gebeuren is dat een user via een bug alle posts op status deleted kan zetten, 1 update query adhv last modified date en je hebt het weer terug...

Ben je echt bang voor teveel rijen in je dbase ( waarom heb je dan een dbase ? ) Dan kan je nog overwegen om elke maand alle posts ouder dan een maand ( via last modified ) met status deleted fysiek te verwijderen met een cronjob.

Gemiddeld forum is heel makkelijk qua rechten in te stellen voor een gewone user hoor, sommige tabellen view rechten, minder tabellen update rechten, nog minder tabellen create rechten...

[NMe]

LauPro schreef op woensdag 01 oktober 2008 @ 23:40:
Zoiets zou ik doen.

Ik begrijp de algehele aversie tegen prepared statements in dit topic niet? IMO is de enige geldige reden om die niet te gebruiken het feit dat je geen MySQLi-ondersteuning hebt.

[LauPro]

Gomez12 schreef op donderdag 02 oktober 2008 @ 00:18:
[...]
Of gewoon verschillende webusers verschillende rechten geven. Bijv op GoT hoef een gewone user afaik nergens delete rechten te hebben, edit rechten alleen op de losse posts, niet op de topics tabel.
Mod krijgt andere webuser toegewezen die wel edit rechten op topics tabel heeft, maar nog geen delete rechten op posts ( dit wordt via een apart veldje bijv geregeld )
Dit is nog wel iets verder uit te breiden met global mod etc. maar in de praktijk gok ik dat dat totaal niet nodig is ( mods zijn al trusted users dus die kan je in dbase meer rechten geven en dan in web de restricties toepassen )

Dit zou een ideale praktijksituatie zijn. Helaas heb je om te detecteren of iets een mod is databaseaccess nodig, je legt dus eerst een connectie naar de DB om dit te checken en vervolgens moet je een nieuwe connectie leggen waar je je 'write secured context' aan gaat roepen. Dit lijkt mij nogal duur en ingewikkelde, onlogische code opleveren, helaas is de mysql_change_user in 3.0.14 geschrapt.

Natuurlijk is het wel zo dat in het geval van een MySQL-replicatieopstelling er al een onderscheid gemaakt moet worden tussen read en write queries, op basis van deze implementatie kan ik mij een eenvoudigere schifting bedenken.

Gemiddeld forum is heel makkelijk qua rechten in te stellen voor een gewone user hoor, sommige tabellen view rechten, minder tabellen update rechten, nog minder tabellen create rechten...

Ik vind het eerlijk gezegd nogal paranoïde om op tabelniveau (en veld-?) rechten toe te delen. Dat getuigt namelijk gewoon dat je je codebase onvoldoende onder controle hebt en een ondeugelijke segregatie hebt toegepast in je design.

-NMe- schreef op donderdag 02 oktober 2008 @ 00:20:
Ik begrijp de algehele aversie tegen prepared statements in dit topic niet? IMO is de enige geldige reden om die niet te gebruiken het feit dat je geen MySQLi-ondersteuning hebt.

Zolang er geen LINQ-achtige implementaties zijn blijven geprepareerde statementen icm SQL een vorm van workaround en een onnodige layer in de applicatie.

[ Voor 12% gewijzigd door LauPro op 02-10-2008 00:35 ]

[Gomez12]

LauPro schreef op donderdag 02 oktober 2008 @ 00:27:
[...]
Dit zou een ideale praktijksituatie zijn. Helaas heb je om te detecteren of iets een mod is databaseaccess nodig, je legt dus eerst een connectie naar de DB om dit te checken en vervolgens moet je een nieuwe connectie leggen waar je je 'write secured context' aan gaat roepen. Dit lijkt mij nogal duur en ingewikkelde, onlogische code opleveren

Hangt ervanaf hoe groot je site is, praktisch is er geen reden om niet meerdere persistent connections open te houden, je hebt alleen in je code een uitdaging om van persistent connection te switchen ( maar als je genoeg bezoekers hebt dan kan dit best de moeite lonen )

Ik vind het eerlijk gezegd nogal paranoïde om op tabelniveau (en veld-?) rechten toe te delen. Dat getuigt namelijk gewoon dat je je codebase onvoldoende onder controle hebt en een ondeugelijke segregatie hebt toegepast in je design.
[...]

Hangt ervanaf hoe groot je bent. Heb je het over 1 developer die voor alles verantwoordelijk is dan is het paranoide, heb je het over een aantal mensen die verantwoordelijk zijn voor de dbase en andere mensen die verantwoordelijk zijn voor de web-frontend dan vind ik het gewoon normaal.
Als dba heb ik geen zin om in de shit te komen als de frontenders ergens een fout maken zolang er geen goede reden voor is.
Maar sowieso zie ik gewoon totaal geen reden voor frontenders om iets uit de dbase te verwijderen, delete rechten zijn gewoon totaal niet nodig. Frontenders of dba's maken maar gewoon een view die alleen de items zonder status verwijderd toont. Frontenders krijgen dan de data die ze willen, dbase heeft nog steeds de oude data staan voor als de shit echt uitbreekt... Stukje risico spreiding.

Op database niveau ga ik er altijd vanuit dat ik mijn codebase niet voldoende onder heb, ongeveer hetzelfde als dat ik er altijd vanuit ga dat mijn sloten op mijn deuren niet toereikend zijn en hiervoor sluit ik een verzekering af.
Ik kan de oude dbase terughalen van backups, maar dat kost tijd. Als ik gewoon de situatie zoveel mogelijk voorkom kost het mij zo weinig mogelijk tijd...

[LauPro]

Gomez12 schreef op donderdag 02 oktober 2008 @ 00:53:
[...]
Hangt ervanaf hoe groot je site is, praktisch is er geen reden om niet meerdere persistent connections open te houden, je hebt alleen in je code een uitdaging om van persistent connection te switchen ( maar als je genoeg bezoekers hebt dan kan dit best de moeite lonen )

Er zijn situaties denkbaar waarbij persistent connections meer ellende veroorzaken dan ze goed doen, bijvoorbeeld bij het gebruik van transacties. Ben het verder met je eens dat het een uitdaging is om de queries over de juiste verbinding te sturen zonder direct de codebase te vervuilen.

Hangt ervanaf hoe groot je bent. Heb je het over 1 developer die voor alles verantwoordelijk is dan is het paranoide, heb je het over een aantal mensen die verantwoordelijk zijn voor de dbase en andere mensen die verantwoordelijk zijn voor de web-frontend dan vind ik het gewoon normaal.
Als dba heb ik geen zin om in de shit te komen als de frontenders ergens een fout maken zolang er geen goede reden voor is.

Ik denk niet dat dit op gaat voor de meeste hobbyprojectjes waar dit topic een vervolg van is. Maar bij een complexe database heb je sowieso al snel segmentatie en partitionering nodig echter bij een grote website wil je meestal je queries zo snel en simpel mogelijk houden.

Maar sowieso zie ik gewoon totaal geen reden voor frontenders om iets uit de dbase te verwijderen, delete rechten zijn gewoon totaal niet nodig. Frontenders of dba's maken maar gewoon een view die alleen de items zonder status verwijderd toont. Frontenders krijgen dan de data die ze willen, dbase heeft nog steeds de oude data staan voor als de shit echt uitbreekt... Stukje risico spreiding.

Hier ben ik het mee eens, ook in acht genomen dat een DELETE-statement relatief duur is. Toch moet ook hier weer je database niet geen vervuilen met allemaal loze views die enkel een beveiligingsgrondslag hebben, dan ben je echt bezig je beveiligingsmodel op de verkeerde plek toe te passen.

Op database niveau ga ik er altijd vanuit dat ik mijn codebase niet voldoende onder heb, ongeveer hetzelfde als dat ik er altijd vanuit ga dat mijn sloten op mijn deuren niet toereikend zijn en hiervoor sluit ik een verzekering af.

De database is natuurlijk de baas als het gaat om het beheer van de data, daar zal de applicatie zich naar moeten schikken. Tegelijkertijd moet je je database beschermen tegen de gebruiker in de applicatie. Dit spel speelt zich af in de verschillende lagen in een applicatie. Het doorbreken van dit model in het kader van een algehele beveiligingsmaatregel vind ik dan ook abject. Het is als een extra ducktape over een pleister heenplakken - het voegt niets toe en veroorzaakt alleen maar ellende.

Ik kan de oude dbase terughalen van backups, maar dat kost tijd. Als ik gewoon de situatie zoveel mogelijk voorkom kost het mij zo weinig mogelijk tijd..

Het is een beetje naïef om te stellen dat alle injecties zich zo makkelijk laten reconvalescentieëren. Je weet natuurlijk nooit precies wat er is gebeurd tenzij je de exact de transactielogs gaat napluizen, dat kan met een site waarbij enkele honderden transacties per seconde zijn een onmogelijke opgave vormen.

[chris]

Het grote probleem met PHP is dat er te veel manieren zijn om dit te doen, en ten minste een daarvan is onveilig. Als de gewone mysql_query functie niet bestond en alleen de prepared statements dan zou 't hele probleem opgelost zijn. Oftewel: er zijn 3 mogelijkheden: nog een functie toevoegen die wél safe is, alle onveilige functies verwijderen (maar dan breek je waarschijnlijk 80% van de bestaande code) of helemaal niet meer in PHP werken.

En inderdaad, er zijn hele bakken nieuwe PHP-programmeurs die daar mee beginnen omdat 't zo makkelijk is (zo ben ik zelf ook begonnen) en helemaal niets weten over SQL-injecties. Als de standaard-functie die in vrijwel iedere tutorial wordt uitgelegd dan fundamenteel onveilig is... Ik ben het wat dat betreft met TS eens: de makkelijkste manier om queries te doen moet ook by default veilig zijn.

[Anoniem: 156876]

chris schreef op donderdag 02 oktober 2008 @ 09:17:
Het grote probleem met PHP is dat er te veel manieren zijn om dit te doen, en ten minste een daarvan is onveilig. Als de gewone mysql_query functie niet bestond en alleen de prepared statements dan zou 't hele probleem opgelost zijn. Oftewel: er zijn 3 mogelijkheden: nog een functie toevoegen die wél safe is, alle onveilige functies verwijderen (maar dan breek je waarschijnlijk 80% van de bestaande code) of helemaal niet meer in PHP werken.

En inderdaad, er zijn hele bakken nieuwe PHP-programmeurs die daar mee beginnen omdat 't zo makkelijk is (zo ben ik zelf ook begonnen) en helemaal niets weten over SQL-injecties. Als de standaard-functie die in vrijwel iedere tutorial wordt uitgelegd dan fundamenteel onveilig is... Ik ben het wat dat betreft met TS eens: de makkelijkste manier om queries te doen moet ook by default veilig zijn.

Het is niet per definitie onveilig om mysql_query te gebruiken. Als er correct gebruik gemaakt van wordt is het net zo veilig als bijv. PDO. Het verwijderen van die functie zal dan ook nooit gaan gebeuren.

Als de tutorials het niet veilig uitleggen, is het dan de fout van PHP? Het moet toch niet veel gekker worden...

[Tiemez]

LauPro schreef op donderdag 02 oktober 2008 @ 00:27:
[...]
opleveren, helaas is de mysql_change_user in 3.0.14 geschrapt.

met MySQLi werkt dat dus wel.

http://nl2.php.net/manual/en/mysqli.change-user.php

[Olaf van der Spek]

Anoniem: 156876 schreef op donderdag 02 oktober 2008 @ 09:27:
Het is niet per definitie onveilig om mysql_query te gebruiken.

Dat zegt chris toch ook niet? Hij wil alleen een functie zien die default safe is, niet default unsafe.

Als de tutorials het niet veilig uitleggen, is het dan de fout van PHP? Het moet toch niet veel gekker worden...

Zelfs de PHP documentatie van mysql_query bevat geen enkel woord over SQL injectie...

[Olaf van der Spek]

Gomez12 schreef op donderdag 02 oktober 2008 @ 00:18:
Of gewoon verschillende webusers verschillende rechten geven. Bijv op GoT hoef een gewone user afaik nergens delete rechten te hebben, edit rechten alleen op de losse posts, niet op de topics tabel.

Dat heeft toch nauwelijks nut, qua beveiliging? Als een delete from posts niet mogelijk is, dan kan een aanvaller toch gewoon update posts set body = '' uitvoeren?

[Olaf van der Spek]

LauPro schreef op donderdag 02 oktober 2008 @ 01:10:
Er zijn situaties denkbaar waarbij persistent connections meer ellende veroorzaken dan ze goed doen, bijvoorbeeld bij het gebruik van transacties.

Tja, ook dat heeft PHP blijkbaar nog steeds niet gefixed...

[Anoniem: 156876]

Olaf van der Spek schreef op donderdag 02 oktober 2008 @ 10:31:
[...]

Dat zegt chris toch ook niet? Hij wil alleen een functie zien die default safe is, niet default unsafe.

[...]

Zelfs de PHP documentatie van mysql_query bevat geen enkel woord over SQL injectie...

Ze geven wel een veilig voorbeeld:

PHP:

// Formulate Query
// This is the best way to perform a SQL query
// For more examples, see mysql_real_escape_string()
$query = sprintf("SELECT firstname, lastname, address, age FROM friends WHERE firstname='%s' AND lastname='%s'",
    mysql_real_escape_string($firstname),
    mysql_real_escape_string($lastname));

Ik weet niet wat jouw definitie van "default" is, maar "volgens het voorbeeld" lijkt mij daar dicht in de buurt komen. En dat is safe. Je wílt niet dat PHP die dingen in handen neemt, dat is de taak van de programmeur!

Het is als PHP.net zijnde geen optie om voor alle mogelijk programmeerfouten een melding te geven in de documentatie. Ze geven een voorbeeld hoe het wél moet, dan is hun deel gedaan. Als de programmeur het dan finaal verkloot, door dit voorbeeld niet te gebruiken maar een andere ranzige, onveilige manier... Wiens fout is het dan?

Verder heeft GoT een hele mooie functie die wel bestaat, namelijk om posts te editten: .

[ Voor 6% gewijzigd door Anoniem: 156876 op 02-10-2008 11:01 ]

[pedorus]

Olaf van der Spek schreef op dinsdag 30 september 2008 @ 15:28:
Zelf dacht ik aan zoiets:

PHP:

mysql_query_safe("insert into T (A, B, C) values (?, ?, ?)", $a, $b,
$c);

Dit is crap, want het is nog steeds veel te lang. Waarom niet zoiets?

PHP:

$a="test";
$b=99;

mysql_query_safe('insert into T (A, B, C) values ($a, $b, $_GET[c])');

Ik zal de functie er ook bij geven:

PHP:

function mysql_query_safe($query) {
    function escaped($matches) {
        $s=$GLOBALS[$matches[1]];
        if ($matches[2]) $s=$s[$matches[2]];
        if (!preg_match('/^-?[0-9]+(?:\.[0-9]+)?(?:E[+-][0-9]+)?$/',$s))
            $s='"'.mysql_real_escape_string($s).'"';
        return $s;
    }
    $query=preg_replace_callback(
        '/\$([a-zA-Z_\x7f-\xff][a-zA-Z0-9_\x7f-\xff]*)(?:\[(.*?)])?/',
        'escaped',$query,-1,$count);
    if ($count>0) return mysql_query($query);
    throw new Exception('No parameters found in querystring');
}

Werkt prima. Veel plezier!

spoiler:

Voor de rest van de mensen raad ik gewoon prepared statements aan. Die zijn hier voor bedacht...

[.oisyn]

chris schreef op donderdag 02 oktober 2008 @ 09:17:
En inderdaad, er zijn hele bakken nieuwe PHP-programmeurs die daar mee beginnen omdat 't zo makkelijk is (zo ben ik zelf ook begonnen)

Mja, toen ik mijn eerste db-enabled script in PHP schreef deed ik het wel meteen goed, ondanks dat 't niet in de tutorial genoemd werd (nou ja, "goed", ik gebruikte destijds nog addslashes()). En ik weiger te geloven dat dat is omdat ik dan een enorm goede programmeur zou zijn oid. 't Is natuurlijk gewoon een kwestie van nadenken wat je aan het doen bent. Helaas doen veel mensen dat niet en nemen ze code gewoon klakkeloos over, zolang het maar werkt. Het eerste waar ik aan denk als ik gecombineerde data op een bepaalde manier moet formatten is "maar wat als er in de data zelf karakters staan die de formatting om zeep helpen?". Een SQL query string is hierin in feite niet anders dan een stukje HTML of een CSV regel.

pedorus schreef op donderdag 02 oktober 2008 @ 11:09:
[...]

Dit is crap, want het is nog steeds veel te lang. Waarom niet zoiets?

PHP:

$a="test";
$b=99;

mysql_query_safe('insert into T (A, B, C) values ($a, $b, $_GET\[c])');

Ik zal de functie er ook bij geven:

Je functie is stuk. Je mag zelf uitvinden waarom
.edit: nvm, ik las verkeerd.

[ Voor 17% gewijzigd door .oisyn op 02-10-2008 11:19 ]

[winkbrace]

reuze leerzaam topic. Keep it up, guys

[Olaf van der Spek]

pedorus schreef op donderdag 02 oktober 2008 @ 11:09:
Dit is crap, want het is nog steeds veel te lang. Waarom niet zoiets?

Omdat je dan geen functie return values meer als parameters kunt gebruiken.

Voor de rest van de mensen raad ik gewoon prepared statements aan. Die zijn hier voor bedacht...
[/spoiler]

Is dat zo? Volgens mij zijn prepared statements om een andere reden bedacht en is dit een mooie bijkomstigheid.

Anoniem: 156876 schreef op donderdag 02 oktober 2008 @ 10:56:
Ze geven wel een veilig voorbeeld:

Ah, gelukkig.

Ik weet niet wat jouw definitie van "default" is, maar "volgens het voorbeeld" lijkt mij daar dicht in de buurt komen. En dat is safe. Je wílt niet dat PHP die dingen in handen neemt, dat is de taak van de programmeur!

Je doet net alsof de mysql_query functie eruit zou worden gesloopt en alleen mysql_query_safe over zou blijven...
Daar heb ik toch niet om gevraagd?

Het is als PHP.net zijnde geen optie om voor alle mogelijk programmeerfouten een melding te geven in de documentatie. Ze geven een voorbeeld hoe het wél moet, dan is hun deel gedaan. Als de programmeur het dan finaal verkloot, door dit voorbeeld niet te gebruiken maar een andere ranzige, onveilige manier... Wiens fout is het dan?

Tja, ik blijf erbij dat PHP wel een handje zou mogen helpen.

Verder heeft GoT een hele mooie functie die wel bestaat, namelijk om posts te editten: [afbeelding].

Ook hier ben ik geneigd GoT de schuld te geven. Andere forums hebben niet voor niets een functie die automatisch opeenvolgende posts merged...
En blijkbaar doet zelfs GoT staff het af en toe verkeerd.

[ Voor 57% gewijzigd door Olaf van der Spek op 02-10-2008 11:24 ]

[disjfa]

Olaf van der Spek schreef op donderdag 02 oktober 2008 @ 10:31:
[...]
Zelfs de PHP documentatie van mysql_query bevat geen enkel woord over SQL injectie...

Waarom zou je in een reference een uitleg willen krijgen over functionaliteiten die niets met de functie die je aan het onderzoeken bent?

[Olaf van der Spek]

disjfa schreef op donderdag 02 oktober 2008 @ 11:28:
[...]

Waarom zou je in een reference een uitleg willen krijgen over functionaliteiten die niets met de functie die je aan het onderzoeken bent?

Eh, wat bedoel je? Dat mysql_query en mysql_real_escape_string niks met elkaar te maken hebben?

[Voutloos]

pedorus schreef op donderdag 02 oktober 2008 @ 11:09:
Voor de rest van de mensen raad ik gewoon prepared statements aan. Die zijn hier voor bedacht...

Check.

Ik heb momenteel de kracht er niet voor om al die regexes na te lopen, maar ik verwacht gewoon dat gegeven functie ook niet perfect is. Bijvoorbeeld met strings vars welke uit een geconcatenatie bestaan, of wat er geberd als je letterlijk een dollar teken wil opslaan, etc. etc.

Óf je weet waar je mee bezig bent en neemt de verantwoordelijkheid op je om hier op een low-level manier mee om te gaan, óf je gebruikt een echte abstractielaag welke enige context begrijpt. Daar valt deze functie dus niet onder, dus hoewel het wellicht een redelijke of misschien wel succesvolle poging is, mag hij wat mij betreft per direct naar /dev/null .

[.oisyn]

Olaf van der Spek schreef op donderdag 02 oktober 2008 @ 11:19:
Is dat zo? Volgens mij zijn prepared statements om een andere reden bedacht en is dit een mooie bijkomstigheid.

Klopt. Volgens mij zijn ze er meer voor bedoeld zodat de dbms van tevoren de query kan parsen en een optimization plan kan bedenken. Gezien de korte lifetime van menig script heb je hier niet zoveel aan, en bovendien worden nonprepared statements "tegenwoordig" net zo goed geoptimized.

Daarnaast wil je een statement eigenlijk ook maar 1x preparen en dan meerdere keren uitvoeren, ipv elke keer opnieuw te preparen (wat zou gebeuren in een wrapper functie) wat aan het doel van prepared statements voorbij gaat.

En blijkbaar doet zelfs GoT staff het af en toe verkeerd.

offtopic:
Ik ben al tijden geen GoT staff meer

---

Overigens nog een opmerking over pedorus's functie - als je al dat pad neemt gebruik dan iig een andere syntax. Anders ben je de sjaak als je per ongeluk een keer double quotes voor je string gebruikt ipv enkele quotes. Bovendien kun je daar ook meteen je regex mee versimpelen.

[ Voor 14% gewijzigd door .oisyn op 02-10-2008 13:08 ]

[T-MOB]

Ik ben zelf van een sprintf-techniek

PHP:

$sql = sprintf('INSERT INTO `T` (`a`,`b`) VALUES (%d,"%s")', $a, esc($b));

geswitcht naar een apart dialect voor queries, met name omdat de sprintf methode z'n beperkingen heeft als je NULL wilt kunnen inserten. Een query wordt nu als volgt uitgevoerd.

PHP:

queryF('INSERT INTO `T` (`a`,`b`) VALUES (@d,@s)', $a,$b);

Prepared statements verder nog nooit _nodig_ gehad -- wel wat slechte ervaringen opgedaan met PHP-extensies die niet bij de klant geinstalleerd bleken te zijn...

[Voutloos]

Olaf van der Spek schreef op donderdag 02 oktober 2008 @ 11:19:
Tja, ik blijf erbij dat PHP wel een handje zou mogen helpen.

Maar de magische oplossing is een utopie.

Ook hier ben ik geneigd GoT de schuld te geven. Andere forums hebben niet voor niets een functie die automatisch opeenvolgende posts merged...

Dat hebben ze echt niet wegens security redenen. En dat soort acties is ook extra complexiteit, dus extra kans op bugs.
En schuld van wat? Dat mensen met verstand van zakan bepaalde type queries geschreven hebben? Sjees wat erg, hou me vast.

En blijkbaar doet zelfs GoT staff het af en toe verkeerd.

1) Maar een klein deel van de staff schrijft queries.
2) Degenen die dat doen, weten wel wat ze doen.
3) Jij weet absoluut niet hoe direct er uberhaupt in queries geroerd wordt.
4) Geen delete rechten maar tig keer tijdens executie van je script tussen db users schakelen jankt ook om fuck-ups.

[ Voor 48% gewijzigd door Voutloos op 02-10-2008 13:31 ]

[.oisyn]

Beter lezen Voutloos, het ging over meerdere posts achter elkaar posten ipv dit forum's edit feature gebruiken

[Voutloos]

Hmz, ok. Maar dan nog heeft de keuze tussen dergelijke features weinig met security te maken.

[pedorus]

Olaf van der Spek schreef op donderdag 02 oktober 2008 @ 11:19:
Omdat je dan geen functie return values meer als parameters kunt gebruiken.

Die kun je sowieso maar beter in een variabele stoppen. En ik dacht dat het je om kortheid ging?

Is dat zo? Volgens mij zijn prepared statements om een andere reden bedacht en is dit een mooie bijkomstigheid.

Nou, security wordt als eerste reden genoemd voor het gebruik in MySQL. Performance is een ander voordeel. (Die extra roundtrip zie ik geen problemen mee, want in situaties zonder prepared statements draait de MySQL server meestal op dezelfde host. Meerdere keren hetzelfde preparen kan nog steeds beter gecached worden dan steeds andere queries.)

Voutloos schreef op donderdag 02 oktober 2008 @ 11:50:
Ik heb momenteel de kracht er niet voor om al die regexes na te lopen, maar ik verwacht gewoon dat gegeven functie ook niet perfect is. Bijvoorbeeld met strings vars welke uit een geconcatenatie bestaan, of wat er geberd als je letterlijk een dollar teken wil opslaan, etc. etc.

Nou, hij is wel safe in de vorm van sql-injection-safe, mits je niet zomaar variabelen aan de query-string gaat concateneren ofzo. En verder moet je niet mysql_real_escape_string uitschakelen door op een verkeerde manier van karaterset te wisselen, maar dat soort problemen hou je altijd zonder prepared statements. Letterlijk een dollar-teken gaat nog mis, maar dat is makkelijk oplosbaar, en komt bijna nooit voor in SQL.

Op deze manier kan type-safe enkel natuurlijk niet, want het type wordt een beetje gegokt aan de hand van de inhoud van de strings. Dat is precies de reden waarom bind_param een string types nodig heeft. Enkel dit is nu juist wat TS niet wil geven.
(Het verschil in snelheid en kortheid van opschrijven daargelaten.)

.oisyn schreef op donderdag 02 oktober 2008 @ 13:05:

---

Overigens nog een opmerking over pedorus's functie - als je al dat pad neemt gebruik dan iig een andere syntax. Anders ben je de sjaak als je per ongeluk een keer double quotes voor je string gebruikt ipv enkele quotes. Bovendien kun je daar ook meteen je regex mee versimpelen.

Wat, dan moet je alsnog een nieuw trucje leren! Zolang je niet goed met fout gaat concateneren, krijg je nu trouwens gewoon een exception

[Olaf van der Spek]

pedorus schreef op donderdag 02 oktober 2008 @ 13:57:
Die kun je sowieso maar beter in een variabele stoppen. En ik dacht dat het je om kortheid ging?

Ja. Een functie return value direct gebruiken is korter dan hem eerst in een variabele stoppen.
Ik zie trouwens echt het nut er niet van in om alles eerst in een variabele te stoppen en dan pas te gebruiken.

Nou, security wordt als eerste reden genoemd voor het gebruik in MySQL. Performance is een ander voordeel. (Die extra roundtrip zie ik geen problemen mee, want in situaties zonder prepared statements draait de MySQL server meestal op dezelfde host. Meerdere keren hetzelfde preparen kan nog steeds beter gecached worden dan steeds andere queries.)

Waarom zou als er geen gebruik wordt gemaakt van prepared statements, de database server meestal lokaal zijn?

Nou, hij is wel safe in de vorm van sql-injection-safe, mits je niet zomaar variabelen aan de query-string gaat concateneren ofzo. En verder moet je niet mysql_real_escape_string uitschakelen door op een verkeerde manier van karaterset te wisselen, maar dat soort problemen hou je altijd zonder prepared statements. Letterlijk een dollar-teken gaat nog mis, maar dat is makkelijk oplosbaar, en komt bijna nooit voor in SQL.

Op deze manier kan type-safe enkel natuurlijk niet, want het type wordt een beetje gegokt aan de hand van de inhoud van de strings. Dat is precies de reden waarom bind_param een string types nodig heeft. Enkel dit is nu juist wat TS niet wil geven.
(Het verschil in snelheid en kortheid van opschrijven daargelaten.)

PHP weet het type van een var toch? Waarom moet je dat dan handmatig nog een keer doorgeven?

[pedorus]

Olaf van der Spek schreef op donderdag 02 oktober 2008 @ 14:13:
Ja. Een functie return value direct gebruiken is korter dan hem eerst in een variabele stoppen.

Mensen die zo'n functie gebruiken zullen de variabelen meestal toch niet bewerken, dus over het algemeen is het korter.

Ik zie trouwens echt het nut er niet van in om alles eerst in een variabele te stoppen en dan pas te gebruiken.

Vaak is het beter voor de leesbaarheid, maar het hoeft inderdaad niet altijd.

Waarom zou als er geen gebruik wordt gemaakt van prepared statements, de database server meestal lokaal zijn?

Omdat in meer professionele omgevingen vaak wel prepared statements gebruikt worden. Cheapo-hoster-XXX daarentegen heeft de db-server en de webserver van een site vaak op dezelfde host draaien.

PHP weet het type van een var toch? Waarom moet je dat dan handmatig nog een keer doorgeven?

Omdat je anders veel vaker een cast moet doen, wat daardoor meer typwerk is. Maar goed, anders gebruik je gewoon PDO (ex. 2), waar die string niet nodig is.