Correct. But prior to 5.3.6 it was not possible to have PDO and MySQL agree on the character set (at least without having root access to the server). And after 5.3.6, the DSN *must* include the charset parameter to make them agree. The common technique of setting the charset via SET NAMES (which most frameworks and libraries do) will not work. So instead you have people using prepared statements thinking that they are safe (since all documentation says so) while they are actually not.
My suggestion is to make them actually safe right from the source rather than requiring an API change. The best solution would be education and raising awareness as well as fixing it in the core. The code is there to do so, all it takes is a single bit change in the source... Again, that's just my opinion... Anthony On Sat, Apr 30, 2011 at 3:12 PM, Rasmus Lerdorf <ras...@lerdorf.com> wrote: > On 04/30/2011 12:05 PM, Anthony Ferrara wrote: >> >> Native prepared statements will completely protect you from injection >> via any of the bound parameters. The wire-level passage of the data >> is completely different (and the data is sent by length, rather than >> by deliminator). As an exercise, view the traffic that's sent to the >> server via Wireshark... As such, they are not subject to proper >> escaping by character set. > > As long as PDO and MySQL agree on which character set is in use bound > parameters are safe in emulated prepares as well. > > -Rasmus > -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
