Het enige wat ik te bizar voor woorden vind is dat er blijkbaar nog veel systemen zijn die hun queries zelf samenstellen ipv stored procedures of prepared statements te gebruiken.
Je datalaag is duidelijk gescheiden van de rest, én omdat code en data compleet gescheiden worden, moet je al een crack zijn om nog met injectie weg te geraken.
Edit op hieronder: een cast "vergeten"? Ik zou denken dat je omzettingen en escaping in je datalaag steekt, zodat je niet telkens opnieuw zelf aan die escaping moet denken. Dat is trouwens ook het meest logische: hoe er ge-escaped moet worden, moet je businesslogica niet weten, dat is de zorg van je datalaag die met je databank praat. En die moet systematisch, op een consequente en voldoende wijze, de nodige formattering en escaping doen van je input. En dat test je dan grondig door er alle mogelijke rommel tegenaan te gooien die je kan bedenken. En dan ben je goed bezig.
Als er dan een systematische flaw inzit, ok, dat kan gebeuren. Dan hoef je jezelf niets te verwijten, je hebt tenminste je best gedaan om het zo proper mogelijk op te lossen. En die flaw kan dan op één punt in je code opgelost worden en het spel is terug potdicht.
Maar programmeurs de grond instampen omdat ze 'soms vergeten te escapen': count me in. Dat zijn mensen die IMHO beter geen software schrijven omdat ze blijkbaar niet logisch kunnen nadenken en ontwerpen.
[Reactie gewijzigd door Bauknecht op vrijdag 21 oktober 2011 12:25]
Waarschijnlijk gebruikt VBulletin geen stored procedures of prepared statements vanwege compatibiliteit met platformen. PDO zit pas standaard in PHP sinds versie 5.1. En veel shared webhosting omgevingen zijn pas net over op PHP5, of draaien zelfs nu nog PHP4.
En ja, als je andere manieren gebruikt voor escaping, en/of dat steeds handmatig moet doen, dan kan er iets fout gaan.
Je kunt met een paar regexes zelf een 'prepared statement' en een PHP array met parameters (die je escaped) 'mergen', en dat richting je database sturen. Precies wat PDO doet als de db-server zelf geen prepared statements ondersteunt. Gegarandeerd net zo veilig als prepared statements, zolang je maar altijd je prepared-statement-queries via die functie naar 'echte' queries ombouwt, die de database snapt.
Er is dus geen enkele reden geen prepared statements te gebruiken als je PHP driver het niet ondersteunt.
$params = array('name' => $_POST['username']);
$db->execute("SELECT * FROM users WHERE username = :name", $params);
// wat er gebeurt: $query split je op pattern ":xyz", je pakt zo de value uit de $params, escaped die, concat hem in een nieuw op te bouwen $query, en voert hem uit de op DB
Tuurlijk haal je dit soort truuks alleen uit als je geen PDO hebt, maar dan zit je tenminste veilig. En niet klagen over string-manipulation performance, want de overhead is verwaarloosbaar klein.
[Reactie gewijzigd door superskippy op vrijdag 21 oktober 2011 15:48]
Mensen die nu nog PHP 4 gebruiken moeten, om in Steve Jobs termen te praten, worden vernietigd met een nucleaire bom
Mja, mensen blijven eigenwijs he, ze willen vaak niet luisteren en blijven lekker strings aan elkaar plakken
[Reactie gewijzigd door onox op vrijdag 21 oktober 2011 20:31]
![[RSS]](http://tweakimg.net/g/if/v2/icons/rss_small.png){kind=icon}
![[quick]](http://tweakimg.net/g/if/icons/world_link_cropped.png){kind=icon}
11:23
10:31
Door 
.
![[show]](http://tweakimg.net/g/if/comments/button_down.png "Reactie uitklappen")
